0

I need to be able to trap a ucrtbase.dll fault in our application, can't seem to find any good way to do it. Is it possible to capture this in the VS debugger to see where we are on the stack when the fault occurs?

We see issues more often these days where our application goes unresponsive and shuts down with nothing in our logs. We do see the following in the Eventlog:

Faulting application name: ****************************** Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf Exception code: 0xc0000409 Fault offset: 0x000000000007286e Faulting process id: 0x3754 Faulting application start time: 0x01d8faaaf85feff3 Faulting application path: ******************************** Faulting module path: C:\WINDOWS\System32\ucrtbase.dll Report Id: b56fdb9c-6b0a-4186-9d0e-73570b51c0d2 Faulting package full name: Faulting package-relative application ID:

Event log shows there is a WER report, with no usable data...

If this is not the proper place to address this query, please advise on the proper forum to post as a ucrtbase Windows issue for tracking.

Additional: I found the following report on ucrtbase.dll with version: 10.0.19041.789: but we are not running WSL -> more likely the problem is in ucrtbase.dll or possibly hardware than an application/platform issue. =-=-= Original: https://github.com/microsoft/WSL/issues/8256

Please advise. Thanks much, -Timothy



tried capturing in debugger for triage, no luck.
Timothy Eichfeld
  • 17
  • 4
  • Possible duplicate of this one. https://stackoverflow.com/a/49781951/5869304. To see if you can catch this in the debugger, Set your debug settings as follows: 1. Enable native code debugging checked, 2. Just my code: un-checked. 3. Enable .NET Framework source stepping: checked. Debug like that and it should take you right to where the problem is occurring. Though I'm not sure your call stack is going to be very helpful at that point, for obvious reasons – Joe Nov 17 '22 at 20:48

0 Answers0