64bit manifest problem / side by side issue

Hi all,

I have a 64bit app that refuses to start, it complains about common controls supposedly amiss (in the event log. the error message popping up when starting the app is something completely useless, of course. "...aplication configuration is incorrect....").

It's built from the same source tree than the corresponding 32bit app, which uses some common controls functionality, however, it used to work and now it suddenly doesn't any more.

Anyone have any hints on how i can systematically go about finding out where the problem is I told VS2005 explicitly to not include or generate any manifests, and yet i end up with a bloody manifest file after linkage. I wonder whether that suddenly got embedded as well and now is wreaking havoc.

Any hints greatly appreciated.

- Balt

Answer this question

64bit manifest problem / side by side issue

Devboy

Since you are statically linking to CRT, CRT manifest is not involved. I suspect that you app already had a manifest for using Common Controls version 6 and that manifest is being referenced in the resources.

Since the manifest was generated for x86 the architecture value will sepcify x86 and that could be causing the problem.

There are 2 way to solve the problem while still using Common Controls version 6.

1.Remove the manifest already in your project for Common control version 6.

Add the following to stdafx.h
#ifdef _UNICODE

#if defined _M_IX86

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")

#elif defined _M_IA64

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='ia64' publicKeyToken='6595b64144ccf1df' language='*'\"")

#elif defined _M_X64

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")

#else

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

#endif

#endif

And change the settings to automatically generate and embed the manifest.
This should automatically generate and embed the correct manifest.

2. Create a manifest specific to each of the platforms.
Change rc command line to pass a define that specifies the target platform for the binary
Conditionally include the correct manifest in the resource file based on the platform the binary is targetting.
Architecure has to be changed for the assembly identity of the manifest and the assembly identity of Common Controls

architecture = "amd64" for x64
architecture = "ia64" for IA64

Hope this helps.

Sridhar Madhugiri
Software Developer
Visual C++
oguevarra
Are you saying that even if you use /MT, you still get a manifest generated for your application

Thanks,
Ayman Shoukry
VC++ Team
Pedro Ferreira
The best way to build without a manifest is to link statically to the CRT using the /MT compiler option.

For managed applications, you will always end up with a manifest since /MD is the only accepted CRT model for CLR applications.

Thanks,
Ayman Shoukry
VC++ Team
bernardus
Sridhar,

thanks! That solved my problem. I forgot that I was actually manually linking a manifest in the resource file, but somewhere in the past days, the conditional compile pragmas for X86 and AMD64 disappeared, so I always had the X86 manifest compiled into the app, which made it blow up on x64.

Thanks again!

- Balt
Nagie_Stopy
Yeah, I should have mentioned that of course. I am linking statically to CRT (/MT). I still get that error on the 64bit XP however. I'm lost, I don't know where else to look. This was not a problem a few days ago.

Funny thing is, dependency walker (64bit edition) doesn't find anything missing in my executable except fo msjava.dll (which of course I do not use or reference, but that has always been discovered as missing, guess thats a dep walker bug)
64bit manifest problem / side by side issue

Answer this question