Unexplained crashes related to ntdll.dll

Question

I have an application that I've written that crashes intermittently, but I'm unable to capture an exception at the application layer. I always get an entry in the event log but doesn't give me much info:

Faulting application name: BCS-UI.exe, version: 1.0.11.0, time stamp: 0x5c0edcbd
Faulting module name: ntdll.dll, version: 10.0.17134.376, time stamp: 0x4358e406
Exception code: 0xc0000374
Fault offset: 0x000d8829
Faulting process id: 0x39b0
Faulting application start time: 0x01d49161c80079a0
Faulting application path: C:\Gogs Local\SMR_Windows_UI\BCS-UI\BCS-UI\bin\Release\BCS-UI.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 1fbc4761-d256-44b0-99b0-4d9d758e4fe0
Faulting package full name: 
Faulting package-relative application ID: 

    - System 

  - Provider 

   [ Name]  Application Error 

  - EventID 1000 

   [ Qualifiers]  0 

   Level 2 

   Task 100 

   Keywords 0x80000000000000 

  - TimeCreated 

   [ SystemTime]  2018-12-11T15:12:28.109191000Z 

   EventRecordID 23318 

   Channel Application 

   Computer Leviathan 

   Security 


- EventData 

   BCS-UI.exe 
   1.0.11.0 
   5c0edcbd 
   ntdll.dll 
   10.0.17134.376 
   4358e406 
   c0000374 
   000d8829 
   39b0 
   01d49161c80079a0 
   C:\Gogs Local\SMR_Windows_UI\BCS-UI\BCS-UI\bin\Release\BCS-UI.exe 
   C:\WINDOWS\SYSTEM32\ntdll.dll 
   1fbc4761-d256-44b0-99b0-4d9d758e4fe0 

As you can see, I get this:

Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll.

I'm not sure what that is or how it relates to the crashes, but I've been able to reproduce it on multiple machines and I'm at a loss on how to determine the cause or prevent it from happening.

Update: I've gotten to a point where the application crashes on startup with the above reason. It gets to the end of the MainWindow constructor (it is a WPF application), sits there for about 10 seconds on a white screen and then dies. I've rolled back to older versions of the software and reproduced this behavior. I have also moved it to another machine and did NOT see this behavior, so my current theory is in agreement with what was said in the comments - that something corrupted the heap and it only gets cleared up on a reboot.

Update 2: I'm able to produce this error message when running outside of the debugger, although when running in the debugger, I'm not able to get it to stop on an exception:

a generic error occurred in GDI+

So that's what I'll be hunting today. Interestingly and disturbingly enough, the app crashes every time on startup, even after rebooting. The same behavior does not occur on other machines at this time.

Obscene

The key info is Exception code: 0xc0000374, which is a heap corruption. I have no experience hunting this down from a .NET app, but there is some information here: blogs.msdn.microsoft.com/calvin_hsia/2015/01/30/… – Bagley

c0000374 this is STATUS_HEAP_CORRUPTION. application error. nothing related to ntdll.dll – Amazonas

@Amazonas Well, it says Faulting module name: ntdll.dll. That's where the problem was found. Although you're right in the sense that the problem wasn't caused by ntdll.dll. – Bagley

Actually, the log entry gives you very much useful info. Setup your system to create a crash dump, load the dump in a debugger and go to the exception address. You will find the exact reason why your app crashes. Heap corruption is often an indicator of badly handled native pointers (P/Invoke). – Precipitin

Hard to diagnose, since the error only surfaces long after the issue was caused. Your best hope is to try Time Travel Debugging. That allows you to go back in time and determine who last wrote to the faulting address. – Newly

NTDLL is merely the canary in the coal mine, it didn't cause this very, very nasty mishap. Heap corruption is typically caused by unmanaged code. We know from your previous question that you use a lot of it, had you answered that question then we might have had a better guess at a cause. Use the AppVerifier utility, something might pop out if you're lucky. – Bantam

@dym: That's not going to help here. The real issue has happened long ago. The callstack isn't useful when analyzing heap corruption bugs. – Newly

@Newly That is super cool! (TTD) I need to bookmark that. – Bagley

Here's my answer from the previous thread Machines are all x64 and target CPU was set to "any" until I changed it to x86 the other day in attempt to fix this issue. Don't ask me why. Will try to reproduce by setting them to x64. – Obscene

By the way, the AppVerifier utility that @HansPassant recommended above caused massive problems and prevented me from running the application in Visual Studio at all. Wasn't until I uninstalled it that I was able to run it again – Obscene

This question without any reproducible code is off topic and should be closed, since it leads to speculation and cannot be correctly answered. – Horehound

@strom off what topic? It's my thread. It IS the topic. Just because you have nothing to contribute doesn't mean it should be closed – Obscene

Answer 1

To debug these kind of system internal issues, I suggest you try Process Monitor.

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.

Basically you need to look out for the "NAME NOT FOUND" errors, which means missing dlls or registry keys, or any other suspisious errors in the monitor screen.

Fungi

This answer was auto-chosen because of my bounty – Obscene

Answer 2

The last time I had a similar crash in my app that pointed to ntdll.dll as the faulting module, the reality was that my own code had a memory leak. I did a strcpy on a string that was not allocated memory. Something like,

char * str;
strcpy(str, "Hello");

I found this after a strenuous walkthrough of my code.

Check your code for leaks.

Quanta

Thanks for that. I did find some potential memory leaks, but it still occurs. I will keep looking – Obscene

This is not a memory leak. A memory leak is if you allocate memory and do not free it after using. Memory leaks don't lead to crashes, unless you leak so much memory that the RAM becomes full and the app crashes because of "out of memory". What you did in your example, is that you write to memory you did not allocate. – Hurricane

Answer 3

For those having a similar issue and only get this error but nothing else:

A breakpoint instruction (__debugbreak() statement or a similar call) was executed

Try update the NuGet packages in your solution.

As soon as I updated a handful of Microsoft packages, that mysterious error stopped occurring.

Saxtuba