Click here to Skip to main content
15,123,118 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi experts, I'm lost...

I have a problem with a legacy W32 application. I'm aware similar was asked here for several times and all the answers didn't help.

One example of an Error Message in the Windows Event Log
Faulting application name: MyApp.exe, version:, time stamp: 0x00000000 Faulting module name: ntdll.dll, version: 10.0.14393.3630, time stamp: 0x5e8d42d1 Exception code: 0xc0000005 Fault offset: 0x00039c0b Faulting process id: 0x130 Faulting application start time: 0x01d621cd3cb9571c Faulting application path: C:\Program Files (x86)\MyPgm\MyApp\MyApp.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 5dbb6dd5-7f90-401f-ac03-659bb0fffa9d Faulting package full name: Faulting package-relative application ID:

Similar logs in Windows Event log for following DLL's

Operating System: Windows 10 LTSB 64Bit

In advance
I cannot reproduce the error in my test environment
I have no chance to debug this on the problematic system

What I don't understand and finally my question
Why for a W32 application all error messages for windows related dll's have the path "C:\Windows\SYSTEM32\" and not "C:\Windows\SysWOW64"?

Sorry not able to be more specific. Any hint is welcome.
Thank you very much in advance.

What I have tried:

Tried to reproduce and google for similar cases
Updated 9-Jul-20 9:04am
ZurdoDev 9-Jul-20 14:02pm
I don't think it really matters whether it says SYSTEM32 or SysWOW64, does it?

But this site is for code questions. I'm not sure you're going to get much help. Especially since there is nothing to go on.

If I were you I'd be more worried about my the app is crashing rather than what the stack trace path shows.
[no name] 9-Jul-20 16:06pm
Thank you for your comment.
"I don't think it really matters whether it says SYSTEM32 or SysWOW64, does it?": I'm only looking for a reasonable explanation why a W32 application finally crashes in a 64Bit Dll.
Richard MacCutchan 10-Jul-20 4:16am
I suggest you try Microsoft. At the very least they may be able to identify which function in ntdll was being called.

1 solution

You should be mostly interested in the error code 0xc0000005 which mean access violation and so points at a bug in your code. So your program is trying to access some bad, locked or not granted resource, often is it memory. I had experinced that it happens only in release builds, because debug builds have some debug bits at the start and ends of allocated memory.

One possible solution is to make some static debug build or write some expensive log file to find the code where the crash happens.

My tip is some free or delete operations, pointer maths or access of handles. So first I would check that freed pointers and closed handles are nulled, and so arent mistakenly reused. Hope your legacy code isnt too messy ;-)
[no name] 9-Jul-20 14:10pm
Thanks for your answer. But why only on one of lot of installations? And why a W32 app ends e.g. in system32\ntdll.dll exception? Ok, the later is maybe only a inacurrate message or most probably (?) SysWOW64\ntdll.dll uses system32\ntdll.dll which finally crashes...

"My tip is some free or delete operations, pointer maths or access of handles": Most code is using TPointer (means as soon one leaves the scope, TPointer will delete the allocated class). And as far as I can tell the rest is clean with using try/finally. But yes of course there is a chance the there is a piece of code (maybe also in one of the used libraries) is not complete safe.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900