/cc @alexbrainman

Try setting the environment variable GOTRACEBACK to "crash".

I should mention that GOTRACEBACK is documented at https://golang.org/pkg/runtime/ .

@ianlancetaylor, thanks, I didn't know about GOTRACEBACK, but it doesn't help here as "crashes in an operating system-specific manner" for Windows is currently a no-op with a TODO comment. See runtime/signal_windows.go (and my second suggestion above):

func crash() {
	// TODO: This routine should do whatever is needed
	// to make the Windows program abort/crash as it
	// would if Go was not intercepting signals.
	// On Unix the routine would remove the custom signal
	// handler and then raise a signal (like SIGABRT).
	// Something like that should happen here.
	// It's okay to leave this empty for now: if crash returns
	// the ordinary exit-after-panic happens.
}

@ianlancetaylor
I believe calling a "crash" function in lastcontinuehandler would cause the exception context record in the dump to point to the crash function. Returning _EXCEPTION_CONTINUE_SEARCH should cause the exception context record to point to the original source of the exception.

Two suggestions:

Sounds good to me.

We can submit a PR if this is agreeable.

That is agreeble from me, thank you.
We use this https://golang.org/doc/contribute.html procedure instead of Github PRs.

I didn't know about GOTRACEBACK

I did know about GOTRACEBACK, but I did not know about "crashes in an operating system-specific manner instead of exiting" if GOTRACEBACK=crash. So the "crashing" part is not implemented on Windows.

I believe calling a "crash" function in lastcontinuehandler would cause the exception context record in the dump to point to the crash function.

Correct.

Returning _EXCEPTION_CONTINUE_SEARCH should cause the exception context record to point to the original source of the exception.

Correct. And that is what @bhiggins is proposing to add.

I think we are all on the same page.

Alex

We have a go+C program on Windows. In absence of coredump, it is hard for us to root cause errors in the C code. Will really appreciate resolution of this issue.

Will really appreciate resolution of this issue.

@usirsiwal try changing runtime yourself and see if it helps you. And if it works for you, submit it here to help others.

If you have problems, just ask for help here.

Alex

@alexbrainman I will try the runtime change and see if it works for us.

Hello,
We came up with the following solution. We had to conditionally remove disableWER to get the crashdump. We are not sure if that is the right thing to do. Please let us know if there is a better way of doing it.

Thanks,
Umesh

diff --git "a/C:\\go1.10.windows-amd64\\go\\src\\runtime\\signal_windows.go.orig" "b/C:\\go1.10.windows-amd64\\go\\src\\runtime\\signal_windows.go"
index 518aac3c4..939379ce4 100644
--- "a/C:\\go1.10.windows-amd64\\go\\src\\runtime\\signal_windows.go.orig"
+++ "b/C:\\go1.10.windows-amd64\\go\\src\\runtime\\signal_windows.go"
@@ -148,7 +148,7 @@ func lastcontinuehandler(info *exceptionrecord, r *context, gp *g) int32 {
        }

        if docrash {
-               crash()
+               return _EXCEPTION_CONTINUE_SEARCH
        }

        exit(2)
@@ -228,6 +228,10 @@ func crash() {
        // Something like that should happen here.
        // It's okay to leave this empty for now: if crash returns
        // the ordinary exit-after-panic happens.
+       _, _, docrash := gotraceback()
+       if docrash {
+               raiseException(0xdead)
+       }
 }

 // gsignalStack is unused on Windows.

 
 
 diff --git "a/C:\\go1.10.windows-amd64\\go\\src\\runtime\\os_windows.go.orig" "b/C:\\go1.10.windows-amd64\\go\\src\\runtime\\os_windows.go"
index 7aeadd9ef..18acc4dcf 100644
--- "a/C:\\go1.10.windows-amd64\\go\\src\\runtime\\os_windows.go.orig"
+++ "b/C:\\go1.10.windows-amd64\\go\\src\\runtime\\os_windows.go"
@@ -80,6 +80,7 @@ var (
        _LoadLibraryA,
        _QueryPerformanceCounter,
        _QueryPerformanceFrequency,
+       _RaiseException,
        _ResumeThread,
        _SetConsoleCtrlHandler,
        _SetErrorMode,
@@ -302,7 +303,10 @@ func osinit() {

        useLoadLibraryEx = (_LoadLibraryExW != nil && _AddDllDirectory != nil)

-       disableWER()
+       _, _, docrash := gotraceback()
+       if docrash {
+               disableWER()
+       }

        externalthreadhandlerp = funcPC(externalthreadhandler)

@@ -445,6 +449,15 @@ func exit(code int32) {
        stdcall1(_ExitProcess, uintptr(code))
 }

+//go:nosplit
+func raiseException(code int32) {
+       stdcall4(_RaiseException,
+               uintptr(code),
+               0,
+               0,
+               0)
+}
+
 //go:nosplit
 func write(fd uintptr, buf unsafe.Pointer, n int32) int32 {
        const (

@usirsiwal @bhiggins i use https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx and try modify runtime according to the above.
go call dll ,crash in dll. but i not found dmp fille. go version go1.11.5 windows/386.

Change https://golang.org/cl/195577 mentions this issue: runtime: enable go programs to crash on windows

there's note about WER ui dialog to avoid to run binaries in self-maintained mode.
and there's DontShowUI registry flag to handle that: https://docs.microsoft.com/en-us/windows/win32/wer/wer-settings

Is it possible to collect a crash/core dump on windows from an application?
Looking at this thread, and the PR/CL it looks like the only option is to modify go.

I tried setting GOTRACEBACK=crash and I can only get a crashdump using RaiseFailFastException. However, that dump is not very usable in delve. It does not have the stack trace of the crashing thread (I'm pretty sure I need to set the Context, but, I don't know to what). Other go routine's show up all right.
Any insight into this would be appreciated.

Is it possible to collect a crash/core dump on windows from an application?
Looking at this thread, and the PR/CL it looks like the only option is to modify go.

Yes, you need to modify Go. You need something like

https://go-review.googlesource.com/c/go/+/195577/

I tried setting GOTRACEBACK=crash and I can only get a crashdump using RaiseFailFastException.

I just discovered RaiseFailFastException. But, yes, RaiseFailFastException might do the trick. The only problem, how do you propose to call RaiseFailFastException when real crash happen? For that you need CL 195577 or similar.

However, that dump is not very usable in delve.

Correct. Delve does not understand Microsoft crash dumps. Microsoft debuggers do. Like WinDbg.

It does not have the stack trace of the crashing thread (I'm pretty sure I need to set the Context, but, I don't know to what). Other go routine's show up all right.

I don't understand this comment.

Alex

Correct. Delve does not understand Microsoft crash dumps

Actually, it does. Sort of. I've only ever tested with minidumps created by procdump.exe I don't know why the ones created the... "natural" way don't work.

Correct. Delve does not understand Microsoft crash dumps

Actually, it does. ...

Thanks for correcting me. I hardly ever use Delve, so I don't keep up with the features. How did you implement the code that reads minidumps? Can you point me to the code?

Thank you.

Alex

How did you implement the code that reads minidumps?

microsoft documented it https://docs.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_header

Can you point me to the code?

https://github.com/go-delve/delve/blob/master/pkg/proc/core/minidump/minidump.go

https://github.com/go-delve/delve/blob/master/pkg/proc/core/minidump/minidump.go

Nice code too.

Alex

Now that there's a change proposed, could this possibly be tagged for Go 1.17 so that this doesn't get missed? This would be a great improvement to post-mortem diagnostics on Windows.

Change https://golang.org/cl/307372 mentions this issue: runtime: enable crash dump creation on Windows without fault reporting UI

I just submitted a third attempt to fix this issue. The change is mostly based on what bhiggins has done(https://go-review.googlesource.com/c/go/+/195577/), but two of the code reviewer's questions are addressed:

1. The WER fault reporting UI is disabled, so no dialog will pop up before the dump creation.
2. When RaiseException() is called, the original exception code will be thrown.

Change https://golang.org/cl/360617 mentions this issue: runtime: do not generate crash dump on Windows 7

The CL's related to this issue have been reverted in CL 362454 so it would be good to reopen it.

See #49471 for context.

The CL's related to this issue have been reverted in CL 362454 so it would be good to reopen it.

Done.

Alex

Moving to backlog.

any news for that?

I've stumbled over that while trying to call Java code via JNI and every Java exception causes to crash the go binary due to this behaviour. Patching lastcontinuehandler in runtime/signal_windows.go to return _EXCEPTION_CONTINUE_SEARCH resolves the issue for me (as suggested in timob/jnigi#31), but patching the framework is not good at all.

I wish there would be an alternate solution for this, because this breaks the whole JNI implementation of my project

@mlaggner no one is working on this issue. But there is this proposal #49471 that might help you.

Alex

Change https://go.dev/cl/474915 mentions this issue: runtime: support GOTRACEBACK=wer on Windows