2

After report from one of our users I've installed a clean Win7 x64 on a VirtualBox virtual machine and attempted to run our WPF .NET Core 3.0 app there. It is definitely crashing every time I close it without any stack trace with a generic C# exception code (e0434352). Event viewer shows a missing Stack trace ("Stack:" and nothing after it).

I've tried running it under WinDbg but all I get is this:

(4e0.608): C++ EH exception - code e06d7363 (first chance)
ModLoad: 000007fe`fb8a0000 000007fe`fb8cc000   C:\Windows\system32\POWRPROF.DLL
(4e0.ab4): Unknown exception - code 0000071a (first chance)
ModLoad: 000007fe`fc860000 000007fe`fc8b7000   C:\Windows\system32\apphelp.dll
ModLoad: 000007fe`edd20000 000007fe`eddbc000   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll

Any ideas on how to debug it further? The crash is reproduced every time I close the program. The program runs fine itself before I try to close it.

Update: (answering comments)

  • we're using a win-x64 self contained deployment;
  • our app handles all first chance exceptions and logs them, there are none before the shutdown (the log looks like the shutdown went properly);
  • our app has an updater written using the same technology stack (WPF .NET Core 3.0 win-x64 self-contained app) and it shuts down properly;
  • just tested it out on another machine (real machine this time) with Win7 x64 - crashes as well;
  • installed Visual Studio on that virtual machine, the program still crashes after I shut down it but Visual Studio doesn't capture anything even if I launch the app in debug mode from VS.

!threads output:

https://pastebin.com/RAz1ZCnU

!pe output:

https://pastebin.com/1C8Eh87f

k output:

https://pastebin.com/yYq51JzC

mephisto123
  • 1,400
  • 13
  • 38
  • Any other errors in Event Viewer? Does the application have exception handling and logging? – Panagiotis Kanavos Mar 21 '19 at 12:24
  • You could try the GETLASTWINDOW32 error but do not think it will give additional info. Normally when code runs and get exception on return it means a stack mis-alignment. Normally if the subroutine and the main function declare the return variable different (subroutine return long while main expects int). Does it fail if you use x86 and AnyCPU? – jdweng Mar 21 '19 at 12:25
  • There are two "Application error" and two "NET Runtime" errors in the event viewer, both of the errors look the same, have no stack trace and the same exception code. – mephisto123 Mar 21 '19 at 12:28
  • Edited my question to answer everything. – mephisto123 Mar 21 '19 at 12:33

1 Answers1

0

WinDbg does not come with .NET support. You need the extension for .NET specific information. Typically .loadby sos clr for .NET and .loadby sos coreclr for .NET Core. Then use !printexception (short: !pe) to get .NET specific details on the exception.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • I tried. It says that there's no module 'coreclr' :( !pe says that there's no export 'pe'. – mephisto123 Mar 21 '19 at 15:31
  • @mephisto123: can you check `lm` to figure out which runtime was loaded? If `.loadby` fails, then there is no `!pe` – Thomas Weller Mar 22 '19 at 13:54
  • @mephisto: there is coreclr in the output: `000007fe'f0bb0000 000007fe'f1129000 coreclr (deferred)` Are you sure this is the same situation. Did you take a crash dump? – Thomas Weller Mar 23 '19 at 12:32
  • Oh so I had to run the app first and only do .loadby when it crashed. No error on .loadby command this time. However, !pe doesn't help as it says there is no managed exception: https://pastebin.com/1C8Eh87f – mephisto123 Mar 23 '19 at 15:18
  • @mephisto123: `!threads` shows all threads and should also list on which thread there is an exception. Please, also create a crash dump, so that we always talk about the same crash, not a new one each time. – Thomas Weller Mar 23 '19 at 16:54
  • Added !threads output to the original question. Not sure how to create a crash dump, I've created one with .dump /f , reloading it shows the same commands output, hopefully that's what I needed. – mephisto123 Mar 24 '19 at 03:31
  • @mephisto123: this will be a neverending discussion. It seems like I'm teaching you WinDbg from scratch. The output of `!threads` seems like there is no managed exception, which contradicts your statement "generic C# exception code (e0434352)". Please read https://stackoverflow.com/questions/24874027/how-do-i-take-a-good-crash-dump-for-net on how to take a good crash dump. `/f` is a kernel switch. Use `/ma` instead – Thomas Weller Mar 24 '19 at 10:18
  • @mephisto123: it also seems you have not [set up symbols correctly](https://stackoverflow.com/a/30019890/480982) – Thomas Weller Mar 24 '19 at 10:21
  • I apologize for being such a newbie in WinDbg, I really had never used it before. That's why I've created this question as reasons of some issues are too cryptic and I don't even have any idea on how to ask Google about it. So I've specified the MS server as the source for the symbols, created a minidump using /ma options and used the commands !pe, !threads and k. Here is the full log of WinDbg since the moment I've initiated the app shutdown including output of all the commands: https://pastebin.com/PpFBp3i3 – mephisto123 Mar 24 '19 at 12:53