Forum Discussion
WindbgTime-travel C# .NET 8.0 app: why is RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
I picked up a couple of months old Visual Studio Solution and found I needed to make a few modifications to enable Time-Travel debugging. After resolving a few hurdles (startup module defined, profiling taking place in the Visual Studio solution), I finally configured the app to be x64/DEBUG. Yet even that would stop in the DirectX layers. Finally, not wanting to make any major changes to the app, I used:
RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
Then the app's dialog/window appeared when being time-travel-debugged.. Obviously, this stops the DirectX use of hardware, but I am curious - is there a better way?
Sam
ps, if need I fan send the call stack that the app stops on with out this line in the Application_Startup routine.
I configured VS2022 with .NET 8.0, changing the Exception settings to enable all exceptions to be trapped. With the "RenderOptions.ProcessRenderMode = RenderMode.SoftwareO", VS stops just like WinDbg/Time-Travel. The exception is 8001010d
the line in VS that stopped on is
HwndTarget.cs:
line 1464: return AutomationInteropProvider.ReturnRawElementProvider(handle, wparam, lparam, el);
Diving into other's sw, but seems How to make thread-safe calls to controls - Windows Forms .NET | Microsoft Learn is at the root of the problem. Windbg's default exceptions handling vs Time-travel vs VS 2022, where the defaults across the set tends to mask the issue. So, Time-Travel doesn't require the software rendering, it's just set to stop on the exception's caused by the app's async implementation.
