0xc000007b on startup in 64bit debug mode, log file???, how to check which DLL ?

Hi,

I'm converting a 32bit app to 64bit in VS2008 and i'm having a startup issue when debugging in 64bit mode, how can you find what DLL it is aborting on? is there a log somewhere? it's not getting to the InitInstance in the app. thanks for your help.

'test.exe': Loaded 'C:\Windows\System32\rpcrt4.dll'
'test.exe': Loaded 'C:\Windows\System32\psapi.dll'
'test.exe': Loaded 'C:\Windows\System32\comdlg32.dll'
'test.exe': Loaded 'C:\Windows\System32\shlwapi.dll'
The program '[3928] test.exe: Native' has exited with code -1073741701 (0xc000007b).


I have loaded the exe in 64bit dependency walker and all shows 64bit except for the usual comdlg32.dll

----------------------

test.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="amd64"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="amd64"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

ok, done a windbg and found possibly something - looks to be loading x86 common controls, but how do I fix that?

CommandLine: "Y:\lees\vc\Test\x64\Debug\test.exe"
Symbol search path is: srv*c:\Symbols*http://msdl.microsoft.com/download/s...ws\symbols\dll
Executable search path is:
ModLoad: 00000001`40000000 00000001`42d87000 test.exe
ModLoad: 00000000`77340000 00000000`774eb000 ntdll.dll
ModLoad: 00000000`77120000 00000000`7723f000 C:\Windows\system32\kernel32.dll
ModLoad: 000007fe`fd600000 000007fe`fd66b000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 000007fe`f8f20000 000007fe`f8f60000 Y:\lees\vc\unrar64.dll
ModLoad: 00000000`77240000 00000000`7733a000 C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fe7b0000 000007fe`fe817000 C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`fe7a0000 000007fe`fe7ae000 C:\Windows\system32\LPK.dll
ModLoad: 000007fe`fddf0000 000007fe`fdeba000 C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fd9a0000 000007fe`fda3f000 C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`fe6c0000 000007fe`fe79b000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fd980000 000007fe`fd99f000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 000007fe`fdae0000 000007fe`fdc0e000 C:\Windows\system32\RPCRT4.dll
ModLoad: 00000000`77500000 00000000`77507000 C:\Windows\system32\PSAPI.DLL
ModLoad: 000007fe`fda40000 000007fe`fdad8000 C:\Windows\system32\COMDLG32.dll
ModLoad: 000007fe`fdfa0000 000007fe`fe011000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 00000000`72ab0000 00000000`72c4e000

C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b

7fabfc\COMCTL32.dll
ntdll!ZwTerminateProcess+0xa:
00000000`7739017a c3 ret

Quote:

---

Originally Posted by hobnob

ok, done a windbg and found possibly something - looks to be loading x86 common controls, but how do I fix that?

---

Windows will always attempt to load the first DLL it finds that matches the name, regardless of whether the DLL is 32-bit or 64-bit. So no magic is being done by Windows to figure out if the DLL is 32-bit or 64-bit -- if the name matches, the OS attempts to load it.

So the answer to your question will be no different than answering "How do I get Windows to load my DLL from this directory instead of that directory?".

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Regards,

Paul McKenzie

fixed it... was an old manifest in the resources with x86.

cheers.