runtime: make crashing more useful on Windows #20498

bhiggins · 2017-05-25T19:44:32Z

What did you do?

Triggered an access violation, crashing the program.

What did you expect to see?

We configured user-mode dumps and were hoping to get a dump (either a full dump or a minidump). See: https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx

What did you see instead?

No dump.

Two suggestions:

In runtime/signal_windows.go, change lastcontinuehandler to return _EXCEPTION_CONTINUE_SEARCH if docrash is true (instead of calling crash and exit(2)-ing). This will allow Windows's crash handling to run instead of being suppressed.
In runtime/signal_windows.go, change crash() to call RaiseException instead of being a no-op.

We can submit a PR if this is agreeable.

bradfitz · 2017-05-25T19:53:58Z

/cc @alexbrainman

ianlancetaylor · 2017-05-25T20:05:01Z

Try setting the environment variable GOTRACEBACK to "crash".

ianlancetaylor · 2017-05-25T20:05:35Z

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

bhiggins · 2017-05-25T21:00:42Z

@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.
}

ptdiscus · 2017-05-26T20:29:33Z

@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.

alexbrainman · 2017-05-28T08:52:08Z

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

usirsiwal · 2018-03-19T17:25:01Z

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.

alexbrainman · 2018-03-20T08:41:32Z

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

usirsiwal · 2018-03-20T12:33:16Z

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

usirsiwal · 2018-03-28T19:16:15Z

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 (

zhaoya881010 · 2019-08-28T13:15:00Z

@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.

gopherbot · 2019-09-16T13:30:19Z

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

ghost · 2020-03-31T08:18:50Z

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

pradipd · 2020-06-03T17:47:49Z

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.

alexbrainman · 2020-06-04T10:50:45Z

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

aarzilli · 2020-06-04T10:56:56Z

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.

alexbrainman · 2020-06-06T01:59:52Z

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

aarzilli · 2020-06-06T05:12:34Z

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

alexbrainman · 2020-06-06T09:09:34Z

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

Nice code too.

Alex

gopherbot · 2021-11-03T06:15:08Z

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

It appears Windows 7 ignores WER_FAULT_REPORTING_NO_UI WerSetFlags API flag. And now after CL 307372, runtime will display WER GUI dialogue. We don't want to introduce random GUI dialogues during Go program execution. So disable dump crash creation on Windows 7 altogether. Updates #20498 Change-Id: Ie268a7d4609f8a0eba4fe9ecf250856b0a61b331 Reviewed-on: https://go-review.googlesource.com/c/go/+/360617 Trust: Alex Brainman <[email protected]> Run-TryBot: Alex Brainman <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Patrik Nyblom <[email protected]>

qmuntal · 2021-11-09T18:06:06Z

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.

alexbrainman · 2021-11-09T20:12:56Z

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

Done.

Alex

ianlancetaylor · 2022-06-24T18:48:40Z

Moving to backlog.

mlaggner · 2022-10-30T07:17:50Z

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

alexbrainman · 2022-11-14T06:57:31Z

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

Alex

gopherbot · 2023-04-06T16:07:48Z

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

GOTRACEBACK=wer is a new traceback level that acts as "crash" and also enables WER. The same effect can be achieved using debug.SetTraceback("wer"). The Go runtime currently crashes using exit(2), which bypasses WER even if it is enabled. To best way to trigger WER is calling RaiseFailFastException [1] instead, which internally launches the WER machinery. This CL also changes how GOTRACEBACK=crash crashes, so both "wer" and "crash" crash using RaiseFailFastException, which simplifies the implementation and resolves a longstanding TODO. Fixes golang#57441 Fixes golang#20498 [1] https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raisefailfastexception Change-Id: I45669d619fbbd2f6413ce5e5f08425ed1d9aeb64 Reviewed-on: https://go-review.googlesource.com/c/go/+/474915 Reviewed-by: Davis Goodin <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Than McIntosh <[email protected]> Reviewed-by: Alex Brainman <[email protected]> Run-TryBot: Quim Muntal <[email protected]>

bradfitz added this to the Go1.10 milestone May 25, 2017

bradfitz added NeedsFix The path to resolution is known, but the work has not been done. OS-Windows labels May 25, 2017

rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017

ianlancetaylor added the help wanted label Jul 10, 2018

ianlancetaylor modified the milestones: Go1.11, Unplanned Jul 10, 2018

alexbrainman mentioned this issue Dec 15, 2018

question: how use SetUnhandledExceptionFilter to golang #29250

Closed

alexbrainman mentioned this issue May 31, 2020

runtime: exit status 0xC0000005 from test process on windows-amd64-longtest builder #38440

Closed

timob mentioned this issue Aug 12, 2020

signal arrived during external code execution timob/jnigi#31

Open

ianlancetaylor added this to the Go1.18 milestone May 4, 2021

gopherbot closed this as completed in 353d5b6 Oct 29, 2021

alexbrainman reopened this Nov 9, 2021

ianlancetaylor modified the milestones: Go1.18, Go1.19 Nov 10, 2021

alexbrainman mentioned this issue Jan 21, 2022

runtime: use MiniDumpWriteDump for GOTRACEBACK=crash on Windows #49471

Open

joedian added this to Release Blockers Jun 15, 2022

ianlancetaylor modified the milestones: Go1.19, Backlog Jun 24, 2022

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022

prattmic added this to Go Compiler / Runtime Jul 25, 2022

prattmic moved this to Triage Backlog in Go Compiler / Runtime Jul 25, 2022

qmuntal mentioned this issue Dec 22, 2022

runtime: use WER for GOTRACEBACK=wer on Windows #57441

Closed

qmuntal mentioned this issue Feb 7, 2023

runtime: support unwinding logical cgo stack transitions using frame pointers #58378

Closed

gopherbot closed this as completed in 65ea4c5 Apr 10, 2023

github-project-automation bot moved this from Triage Backlog to Done in Go Compiler / Runtime Apr 10, 2023

github-project-automation bot moved this to Done in Release Blockers Apr 10, 2023

mknyszek removed this from Go Compiler / Runtime Apr 19, 2023

golang locked and limited conversation to collaborators Apr 9, 2024

gopherbot added the FrozenDueToAge label Apr 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

runtime: make crashing more useful on Windows #20498

runtime: make crashing more useful on Windows #20498

bhiggins commented May 25, 2017 •

edited

Loading

bradfitz commented May 25, 2017

ianlancetaylor commented May 25, 2017

ianlancetaylor commented May 25, 2017

bhiggins commented May 25, 2017

ptdiscus commented May 26, 2017

alexbrainman commented May 28, 2017

usirsiwal commented Mar 19, 2018

alexbrainman commented Mar 20, 2018

usirsiwal commented Mar 20, 2018

usirsiwal commented Mar 28, 2018

zhaoya881010 commented Aug 28, 2019 •

edited

Loading

gopherbot commented Sep 16, 2019

ghost commented Mar 31, 2020

pradipd commented Jun 3, 2020

alexbrainman commented Jun 4, 2020

aarzilli commented Jun 4, 2020

alexbrainman commented Jun 6, 2020

aarzilli commented Jun 6, 2020

alexbrainman commented Jun 6, 2020

gopherbot commented Nov 3, 2021

qmuntal commented Nov 9, 2021

alexbrainman commented Nov 9, 2021

ianlancetaylor commented Jun 24, 2022

mlaggner commented Oct 30, 2022

alexbrainman commented Nov 14, 2022

gopherbot commented Apr 6, 2023

runtime: make crashing more useful on Windows #20498

runtime: make crashing more useful on Windows #20498

Comments

bhiggins commented May 25, 2017 • edited Loading

What did you do?

What did you expect to see?

What did you see instead?

bradfitz commented May 25, 2017

ianlancetaylor commented May 25, 2017

ianlancetaylor commented May 25, 2017

bhiggins commented May 25, 2017

ptdiscus commented May 26, 2017

alexbrainman commented May 28, 2017

usirsiwal commented Mar 19, 2018

alexbrainman commented Mar 20, 2018

usirsiwal commented Mar 20, 2018

usirsiwal commented Mar 28, 2018

zhaoya881010 commented Aug 28, 2019 • edited Loading

gopherbot commented Sep 16, 2019

ghost commented Mar 31, 2020

pradipd commented Jun 3, 2020

alexbrainman commented Jun 4, 2020

aarzilli commented Jun 4, 2020

alexbrainman commented Jun 6, 2020

aarzilli commented Jun 6, 2020

alexbrainman commented Jun 6, 2020

gopherbot commented Nov 3, 2021

qmuntal commented Nov 9, 2021

alexbrainman commented Nov 9, 2021

ianlancetaylor commented Jun 24, 2022

mlaggner commented Oct 30, 2022

alexbrainman commented Nov 14, 2022

gopherbot commented Apr 6, 2023

bhiggins commented May 25, 2017 •

edited

Loading

zhaoya881010 commented Aug 28, 2019 •

edited

Loading