Crashes with no Crash Dump

Hi.

I’ve been experiencing GP crashes (in Win 11) with no dump (or UI) being produced.

Crashes have happened upon: clicking an LED widget, leaving Edit mode, other things. I mention because it doesn’t seem offhand like 3rd party plugins would be the cause, but of course a crash dump is how to get better actual insight.

Is there a way I can ensure that a crash dump takes place in all cases so that it can be submitted for potential diagnosis? (I have SysInternals and thus Procdump available, FWIW)

Have you checked in C:\Users\your_user_name\AppData\Local\GPErrorHandler\UnsentCrashReports\Gig Performer ?

There are some older reports there, but nothing in the past week, during which there have been several crashes.

So what happens: does Gig Performer simply quit and dissapear with no prompts?

Exactly.

Can you please try to reproduce with the built-in templates?

I am hoping for a direct answer to:

Is there a way I can ensure that a crash dump takes place in all cases so that it can be submitted for potential diagnosis?

I’m assuming that one or more people whose combined GP and Windows knowledge exceeds my own can answer this definitively, either Yes or No.

If the answer is No, my followup question would be “Could that be made possible at a future point, or is it inherently impossible?”.

Thanks.

It’s up to your system to produce that crash dump - it’s not something we control.

It seems this technical issue ( Technical issue on the forum ) has taken away the more recent posts from this thread.

@dhj Were you able to download the dumps you asked for from the links I posted yesterday?

Hi @progster

I suspect that a 3rd party application might have override the crash handler in your system and this is why you don’t get a prompt.

Please do the following:

  • Open Registry Editor (run regedit.exe from command line).
  • Paste the following path at the top edit box:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

There should be a “Debugger” entry, please let me know what is the Data of that entry.

1 Like

Thank you kindly for your reply Dadi !

Here is the info:

I take this to indicate I have no automatic debugging currently installed, yes?

I found these articles:

that seem they would be relevant. Alternative debuggers are presented. I know that I have at least WinDbg and Procdump available here as possibilities.

I don’t know where GP’s crash handling fits into the scheme. That would be good to understand.

Also, any successful experiences where someone can say “I attached (this particular) debugger, like so, got the dumps I needed when GP crashed, and was able to successfully diagnose the cause(s) of the crash in my setup.” would be very helpful as a guide to replicate here.

Well, @dadi 's example refers to the Visual Studio Just In Time debugging handler.
But you should probably have the windbg entry - not sure why you have “value not set”

@dhj Here again are the links to the dumps you asked me to upload previously.

These are GP crashes that happened while using a supplied template.

Hi @progster

GP is automatically crashing when detecting a debugger attached to it. Looks like both of these crashes are a result such case.
This is by design in order to protect GP and you cannot attach a debugger.

If a regular crash happens then a dump file should be created by Windows even if no window popped out. You can try to use application like Everything from voidtools which is indexing the whole file system to immediately locate the created dmp file wherever it is (great utility in any case).

@Dadi Excellent information, thank you!

I now have one specific observed no-dump scenario:

I downloaded Everything, used it to help cleanup old .dmp files, and then used it to watch for a new .dmp as I used GP.

I was saving a patch name in U-he Diva (inside of Unify, inside of GP), got a dialog complaining of incorrect characters in the patch name, and then a crash. No .dmp was generated.

I know it is a wishful future “if”, but if GP could sandbox plugins, would/could something like this have been caught and handled without GP crashing? Or is it the case that a crash lower in the hosting chain always carries the possibility of crashing the parent, despite all efforts?

if GP could sandbox plugin

Having a better crash handler is always good and this is a good report!
We will check this internally to find better ways to handle such crashes of 3rd party plugins.

In general, moving plugin processes into a different process is problematic as it will create latency when synching the real-time audio buffers between the processes. But catching synchronized exceptions might be able to be improved. We need to investigate this further.

Regarding the crash you mentioned, let try to find the root cause of it and resolve it so you can move on.

Did you get a new dump file (try using Everything)?
Do you get a crash when using Diva without Unify?
If not then the problem is probably inside Unify and we need to sync Unify developers with this information.

I was hoping I could go thru steps to reproduce this one reliably. Unfortunately not.

I have seen several crashes since my last report, but none of them created dumps.

do you mean even with Everything application you can’t see any new dumps created?

Yes, that’s right.

Here is a different observation that I’ve seen several times lately, incl. this morning -

Start file playback in the SAFP. The file plays (sounds OK), but all UI to GP is lost. Mouse and/or keyboard actions have no effect. Nothing I’ve tried so far will make the UI responsive again. The file will play to the end, if I let it, but reaching the end does not change the situation.

So, ultimately, I quit GP via the Task Manager (End Task). No crash dump is created (per Everything).