1

I am facing lot of issue to exe crash on production server however I want to dump file when exe crash with detail log.

I have found procdump tool. Can you suggest code c# which manually crash exe, so can check what kind of information get in dump log.

Hatted Rooster
  • 35,759
  • 6
  • 62
  • 122
Jigar Joshi
  • 133
  • 1
  • 13
  • 4
    `throw new Exception();` <= and then do not catch the exception anywhere down the call stack. – Igor Nov 10 '16 at 12:23
  • Raise exception? Load an other platform assembly (x86/x64) – Jeroen van Langen Nov 10 '16 at 12:23
  • What kind of crash are you looking for? – Luaan Nov 10 '16 at 12:23
  • FYI: [How do I take a good crash dump for .NET](http://stackoverflow.com/questions/24874027/how-do-i-take-a-good-crash-dump-for-net/24874028#24874028) – Thomas Weller Nov 10 '16 at 12:25
  • I am getting out of memory exception and exe break down on server, so looking forward to dump all information how many objects are loaded and its state. – Jigar Joshi Nov 10 '16 at 12:37
  • Then see also: [How to use WinDbg to track down .NET out of memory exceptions](http://stackoverflow.com/questions/26142607/how-to-use-windbg-to-track-down-net-out-of-memory-exceptions/26150591#26150591) – Thomas Weller Nov 10 '16 at 14:25

2 Answers2

5

A crash is caused by an exception which is not caught. Just throw one in your code

throw new Exception();

and do not add a try-catch block anywhere.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
2

The best, which can't be caught, is creating a stack overflow exception. This one will fall thru the try/catches...

void MyMethod()
{
    MyMethod();
}
Jeroen van Langen
  • 21,446
  • 3
  • 42
  • 57
  • 1
    When built in __Release__ configuration (optimizations enabled), this should not crash (due to [tail-call optimizations](https://en.wikipedia.org/wiki/Tail-call_optimization)). – Jeppe Stig Nielsen Nov 10 '16 at 12:26
  • 1
    can you substantiate this? – Jeroen van Langen Nov 10 '16 at 12:28
  • When built that way, the run-time will choose to optimize things by not creating a new "frame" on the call stack for each recursion, so this will become similar to `here: goto here;` or `while (true) { }` neither of which will crash the application. It is easy to verify by pasting your code into Visual Studio, be sure to have "Release" in the Solution Configurations drop-down, and then run without debugging (Ctrl+F5), for example. – Jeppe Stig Nielsen Nov 10 '16 at 12:36
  • Thanks for the info. With that info i would use the debug build for this test. – Jeroen van Langen Nov 10 '16 at 12:42
  • 2
    Correction: In fact I could not corroborate my own claim, following my own instructions above. I was quite sure I tried this earlier with success. Maybe it was changed in some (recent) version of the CLR, or maybe it depends on the hardware or some additional setting that I am not aware of. – Jeppe Stig Nielsen Nov 10 '16 at 13:09