0

This app statically links multiple mfc dlls and loads those at app startup. But in some cases when CPU usage is high it crashes while activating the frame window. This crash due to AfxGetThread returning NULL in mfc140!CFrameWnd::OnActivateTopLevel at app startup. It has only crashed in client domains and while debugging through time travel debugger in local system. Client domain crash has mostly happened while user was starting a new session in morning. So there may have been some load.

The apps main window is part of a mymain.dll. I added some logs to the mymain dll's app object ctor to log threadid. When I run the app normally on my system it calls the app object ctor on the same thread that calls mfc140!CFrameWnd::OnActivateTopLevel and does not crash. But when I run the app through time travel debugger it calls the app object ctor on another thread that is not the main thread and later crashes on main thread in CFrameWnd::OnActivateTopLevel

00 MyMain!CMyMainApp::CMyMainApp
01 MyMain!`dynamic initializer for 'theApp''
02 ucrtbase!initterm
03 MyMain!dllmain_crt_process_attach
04 MyMain!dllmain_dispatch
05 mscoreei!CorDllMain
06 mscoree!_CorDllMain_Exported
07 ntdll!LdrpCallInitRoutine
08 ntdll!LdrpInitializeNode
09 ntdll!LdrpInitializeGraphRecurse
10 ntdll!LdrpInitializeGraphRecurse
11 ntdll!LdrpInitializeProcess
12 ntdll!LdrpInitialize
13 ntdll!LdrInitializeThunk

Please help understand why the loader is loading this mfc dll on a background thread on certain conditions?

devstability
  • 29
  • 6
  • 1
    If you have a Time Travel Debugging trace, then why aren't you using that to determine the root cause? From the looks of it you are falling victim to the unspecified order of initialization of global variables. And while you're apparently loading the CLR into your process you'll have to follow the protocol **to the letter* (I don't know what that protocol is). – IInspectable Jun 23 '22 at 16:18
  • @IInspectable The trace recording starts after all the static initialization is done. breakpoint on the app object is not hit. Trace starts at 70:0 instead of 0:0. And kernel trace is not supported yet. – devstability Jun 24 '22 at 04:28
  • That's less than optimal then. Still, how do you wind up taking a dependency on the CLR? Are you actively using .NET code in your program, or does MFC just do that, proactively, to be prepared for clients that do? – IInspectable Jun 24 '22 at 07:42
  • @IInspectable dll is native but there are few .net dependencies that are #imported. – devstability Jun 30 '22 at 16:40
  • Created a sample project with same setup. MFC app, MFC regular dll with dependency on managed com lib. Dont get the CORDllMain call in callstack for the app ctor. – devstability Jul 08 '22 at 15:15
  • @IInspectable What is the solution to "unspecified order of initialization of global variables. ". Also Can you please help raise a bounty on this ? – devstability Jul 10 '22 at 09:55
  • The solution to the problem that the order of initialization (and destruction) of objects with static storage duration is unspecified is to not rely on any order. Not actually a solution if you don't control the code that does (such as library code). I'd happily place a bounty on this question if you can produce a [mcve] that demonstrates the issue. – IInspectable Jul 11 '22 at 15:55
  • Windows 10 has parallel loader - https://stackoverflow.com/a/42789684/9265719 so its not order of initialization ? I already tried a sample to get a mfc dll to load from CorDllMain. Why a mfc dll built without /clr is being loaded by CorDllMain – devstability Jul 13 '22 at 14:53
  • Also tried the Maxloaderthreads=1 reg key but still crashes in ttd. – devstability Jul 13 '22 at 15:15

0 Answers0