Ntdll.dll crash for W32 app on windows 10/64, one time more

Question

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: 2.0.0.0, 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
ntdll.dll
KERNELBASE.dll
user32.dll

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

Posted 9-Jul-20 7:10am

User 11060979

Updated 9-Jul-20 8:04am

v4

Add a Solution

Comments

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

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

KarstenK · Answer 1 · 2020-07-09T08:04:00

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 ;-)