Faulting module ntdll.dll error in net10

Bevan Thomas 0 Reputation points

I have an application which has both its 32-bit and 64-bit variant.I recently retargetted it to net10 from net8.64-bit application works fine.But the 32-bit application crashes with following error -:

Faulting module name: ntdll.dll, version: 10.0.19041.6456, time stamp: 0x5f1a1fa5

Exception code: 0xc0000374

Fault offset: 0x000f4b53

Faulting process id: 0x8f8

Faulting application start time: 0x01dcb207f3ab8556

The error happpens where we call managed code from unmanaged code.

  1. RLWA32 52,571 Reputation points

    The exception code indicates that the underlying issue resulted in heap corruption. The likely cause is a marshaling problem between the managed and unmanaged code (pinvoke or COM interop). There's nothing specific that can be diagnosed in the absence of more detail about the executing code.

Sign in to comment

1 answer

  1. Jack Dang (WICLOUD CORPORATION) 18,970 Reputation points • Microsoft External Staff • Moderator

    Hi @Bevan Thomas ,

    Thanks for reaching out.

    Looking at this more closely, the exception code 0xc0000374 usually indicates heap corruption, meaning memory was likely misused earlier and Windows only detected it later. When the crash appears in ntdll.dll, it often means the operating system noticed the corrupted memory there rather than it being the original source.

    What stands out to me is that the problem only happens in the 32-bit build, while the 64-bit version runs without crashing, and it occurs during unmanaged-to-managed calls. With that in mind, I’d lean toward reviewing the interop boundary between native and managed code, since small differences in memory layout can show up only in x86.

    Some areas that might be worth checking include struct layouts, pointer representations, and calling conventions. Also, if unmanaged code stores a pointer to a managed delegate, it’s possible the delegate could be collected by the garbage collector unless a reference is kept on the managed side.

    Since heap corruption is usually detected after the actual problem occurs, enabling Page Heap with gflags can help catch invalid memory writes closer to the source. Microsoft documents this approach here:

    https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enable-page-heap

    https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap

    If you found my response helpful or informative in any way, I would greatly appreciate it if you could follow this guidance provide feedback. 

    Thank you.

    1. Jack Dang (WICLOUD CORPORATION) 18,970 Reputation points • Microsoft External Staff • Moderator

      Hi @Bevan Thomas ,

      If you're still interested or have any questions, feel free to reach out whenever it works best for you. 

    Sign in to comment
Sign in to answer

Your answer