Skip to content

runtime: should not display Windows Error Reporting (WER) dialogue #9121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alexbrainman opened this issue Nov 18, 2014 · 5 comments
Closed

Comments

@alexbrainman
Copy link
Member

Brad suggest we disable WER here
https://groups.google.com/d/msg/golang-dev/QJ-W2FGfq7c/kZONgbJT5Y0J

I agree. It is not useful for debugging Go programs. And it leaves crashed programs
running on our builder. And we use that approach in our compilers already anyway -
search lib9/main.c for SetErrorMode.

I applied this:

diff --git a/src/runtime/os_windows.c b/src/runtime/os_windows.c
--- a/src/runtime/os_windows.c
+++ b/src/runtime/os_windows.c
@@ -31,6 +31,7 @@
 #pragma dynimport runtime·NtWaitForSingleObject NtWaitForSingleObject "ntdll.dll"
 #pragma dynimport runtime·ResumeThread ResumeThread "kernel32.dll"
 #pragma dynimport runtime·SetConsoleCtrlHandler SetConsoleCtrlHandler "kernel32.dll"
+#pragma dynimport runtime·SetErrorMode SetErrorMode "kernel32.dll"
 #pragma dynimport runtime·SetEvent SetEvent "kernel32.dll"
 #pragma dynimport runtime·SetProcessPriorityBoost SetProcessPriorityBoost "kernel32.dll"
 #pragma dynimport runtime·SetThreadPriority SetThreadPriority "kernel32.dll"
@@ -64,6 +65,7 @@
 extern void *runtime·ResumeThread;
 extern void *runtime·SetConsoleCtrlHandler;
 extern void *runtime·SetEvent;
+extern void *runtime·SetErrorMode;
 extern void *runtime·SetProcessPriorityBoost;
 extern void *runtime·SetThreadPriority;
 extern void *runtime·SetUnhandledExceptionFilter;
@@ -106,14 +108,24 @@
    return info.dwNumberOfProcessors;
 }
 
+#define SEM_FAILCRITICALERRORS     0x0001
+#define SEM_NOGPFAULTERRORBOX      0x0002
+#define SEM_NOALIGNMENTFAULTEXCEPT 0x0004
+#define SEM_NOOPENFILEERRORBOX     0x8000
+
 void
 runtime·osinit(void)
 {
    void *kernel32;
    void *addVectoredContinueHandler;
+   uint32 errormode;
 
    kernel32 = runtime·stdcall1(runtime·LoadLibraryA, (uintptr)"kernel32.dll");
 
+   // don't display the crash dialog
+   errormode = (uint32)runtime·stdcall1(runtime·SetErrorMode, SEM_NOGPFAULTERRORBOX);
+   runtime·stdcall1(runtime·SetErrorMode, errormode | SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
+
    runtime·externalthreadhandlerp = (uintptr)runtime·externalthreadhandler;
 
    runtime·stdcall2(runtime·AddVectoredExceptionHandler, 1, (uintptr)runtime·exceptiontramp);

to version with problem (see issue #9106)

changeset:   21782:d8a076541f57
branch:      dev.garbage
parent:      21781:c957f50feeba
parent:      21769:7667e41f3ced
user:        Russ Cox <rsc@golang.org>
date:        Fri Nov 14 12:09:42 2014 -0500
summary:     [dev.garbage] all: merge dev.power64 (7667e41f3ced) into dev.garbage

and WER dialogue disappears.

I will wait until the source tree opens, and send this fix then.

Alex
@minux
Copy link
Member

minux commented Dec 31, 2014

@alexbrainman now that the tree re-opens, do you plan to send that CL?

@alexbrainman
Copy link
Member Author

Will do. I am thinking how to test it. Perhaps we could temporarily disable our exception handler during a test and throw exception.

Alex

@minux
Copy link
Member

minux commented Dec 31, 2014

On Dec 30, 2014 7:09 PM, "alexbrainman" notifications@github.com wrote:

Will do. I am thinking how to test it. Perhaps we could temporarily
disable our exception handler during a test and throw exception.
Yeah, testing is hard, could we just manually test it?

@alexbrainman
Copy link
Member Author

I will see how complicated the test gets.

@alexbrainman
Copy link
Member Author

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants