Why is my 64-bit C++ app crashing?

Question

I have written a really small 64-bit application that crashes on clean installations of Windows Vista x64. It runs smoothly on my development machine (Windows 7 64-bit), which has Visual Studio 2008 installed.

The 64-bit C++ application (unmanaged) is started by a 32-bit .NET application, and crashes immediately afterwards with an access violation error. This is what the Event Viewer says:

Faulting application MaxTo64.exe, version 0.0.0.0, time stamp 0x49a41d9e, 
faulting module USER32.dll, version 6.0.6001.18000, time stamp 0x4791adc5, 
exception code 0xc0000005, fault offset 0x00000000000236d6, process id 0x82c, 
application start time 0x01c996a346a3e805.

MaxTo64.exe 
0.0.0.0 
49a41d9e 
USER32.dll 
6.0.6001.18000 
4791adc5 
c0000005 
00000000000236d6 
82c 
01c996a346a3e805

I have installed the VC2008 redistributable (2008 x86, 2008 x64, 2008 SP1 x86 and 2008 SP1 x64), so this should not be the problem. Edit: It might be worth mentioning that before installing the vcredist-package, it crashed differently, with a side-by-side configuration error.

I am a C++ n00b, so I really have no idea where to look next.

Edit: Output from Debugging Tools for Windows.

CommandLine: "C:\Program Files (x86)\MaxTo\MaxTo64.exe" maxto_a_do_run_run
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00000001`3f2f0000 00000001`3f30b000   MaxTo64.exe
ModLoad: 00000000`77160000 00000000`772e0000   ntdll.dll
ModLoad: 00000000`77030000 00000000`7715b000   C:\Windows\system32\kernel32.dll
ModLoad: 00000001`80000000 00000001`80011000   C:\Program Files (x86)\MaxTo\Hooker.dll
ModLoad: 00000000`76f60000 00000000`7702d000   C:\Windows\system32\USER32.dll
ModLoad: 000007fe`fed70000 000007fe`fedd3000   C:\Windows\system32\GDI32.dll
ModLoad: 000007fe`fea20000 000007fe`feb28000   C:\Windows\system32\ADVAPI32.dll
ModLoad: 000007fe`fe850000 000007fe`fe98f000   C:\Windows\system32\RPCRT4.dll
ModLoad: 000007fe`fd8b0000 000007fe`fe502000   C:\Windows\system32\SHELL32.dll
ModLoad: 000007fe`fef70000 000007fe`ff00c000   C:\Windows\system32\msvcrt.dll
ModLoad: 000007fe`feee0000 000007fe`fef53000   C:\Windows\system32\SHLWAPI.dll
(3a4.964): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
ntdll!DbgBreakPoint:
00000000`771a4ea0 cc              int     3
0:000> g
ModLoad: 000007fe`fe780000 000007fe`fe7ad000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`ff010000 000007fe`ff111000   C:\Windows\system32\MSCTF.dll
ModLoad: 000007fe`feed0000 000007fe`feedd000   C:\Windows\system32\LPK.DLL
ModLoad: 000007fe`fede0000 000007fe`fee7a000   C:\Windows\system32\USP10.dll
ModLoad: 000007fe`fc150000 000007fe`fc349000   C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6001.18000_none_152e7382f3bd50c6\comctl32.dll
(3a4.964): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\USER32.dll - 
USER32!DisableProcessWindowsGhosting+0x1a:
00000000`76f836d6 66f2af          repne scas word ptr [rdi]
*** ERROR: Module load completed but symbols could not be loaded for MaxTo64.exe
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\kernel32.dll -

The call stack at that point is:

USER32!DisableProcessWindowsGhosting+0x1a
USER32!ChangeWindowMessageFilter+0x12d
USER32!RegisterClassExW+0x25
MaxTo64+0x11e4
MaxTo64+0x1075
MaxTo64+0x1920
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x21

It seems to be in MyRegisterClass, which looks like this:

ATOM MyRegisterClass(HINSTANCE hInstance)
{
WNDCLASSEX wcex;

wcex.cbSize = sizeof(WNDCLASSEX);

wcex.style   = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = WndProc;
wcex.cbClsExtra  = 0;
wcex.cbWndExtra  = 0;
wcex.hInstance  = hInstance;
wcex.hIcon   = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_MAXTO64));
wcex.hCursor  = LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszClassName = szWindowClass;
wcex.hIconSm  = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

return RegisterClassEx(&wcex);
}

EDIT: Turns out the problem was my own stupid fault. Apparently, there is a field in the WNDCLASSEX-structure that is not initialized properly. This crashes on Vista, but not on Windows 7, strangely enough. Adding this fixes the problem.

wcex.lpszMenuName   = NULL;

Answer 1

Does your application crash even if you run it from the shell or cmd line?

Answer 2

How about a debugger? Some code to where it crashes?

Also, don't do silly things such as storing pointers in an int - it won't fit anymore.

Answer 3

You have an access violation, you are most likely trying to read from or write to invalid memory.

Answer 4

Seriously there's not much we can infer from your data:

I advice to do at least one of the following items

• Install a VS in the Vista 64 machine
• Setup a remote debug session http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx
• Use OutputDebugString to print info where your program is and watch it with DebugView to narrow where is it crashing.

Edit: After watching only your debug trace I've just come out with two possible problems:

• You don't ZeroMemory WNDCLASSEX, so perhaps Vista is trying to use lpszMenuName.
• Win7 is beta and probably is hiding a bug.

But still you are not showing much code and the trace is incomplete, so it is difficult to assert something without being psychic.

If you copy the .pdb generated by VS to the Vista machine, in the same folder where is your .exe, you will have a more meaningful trace.

Answer 5

Install Debugging Tools for Windows and get a real backtrace - that should lead you to what's happening

Answer 6

Exception code 0xc0000005 is an access violation: your program tried to write to or read from memory it didn't own, most likely. The common reason for this in C/C++ is using a null pointer. Since the exception happened in USER32.dll, you probably passed a null pointer. Since you're using C++, it might involve an object rather than a structure, or a method in some object/class that wraps USER32.dll functions too.