Mikołaj Zalewski a écrit :
I've written a dialog about a crash some time ago to add to winedbg (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html). It's probably time to ask what is the status of this patch? If this patch gets accepted (Alexandre seemed to like the previous version, but pointed that it broke kernel32 tests because there had been no way to disable it and he didn't have much time to review it), maybe calling `winedbg --auto` from ReportFault would be the best way
- you would then have a dialog (the same as during a regular crash,
can be disabled from the registry), the full debugger output and an option to run an interactive debugger. AFAIK this is the other way round than Windows does (AFAIK drwatson loads faultrep.dll into the process that crashed and calls ReportFault), but loading a DLL into a process where everything could be corrupted seems a strange idea.
Jérôme Gardou pisze:
Most wine users, when their app crashes, open a bug report and attach the console log. If the log contains information got from ReportFault, developers will gain some time, and have the preceding context of the call.
I'm affraid this is what is done by the 1% best users ;). I'd expect that a typical user to complain that Linux is broken because on Linux, from time to time, apps just disappear from the screen while on Windows they don't. Already knowing that there is such a thing like Wine requires some knowledge :).
Mikołaj Zalewski
Instead of reinventing the wheel, why not call kernel32 which does it for us.... What do you think about this patch?
From 8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= jerome.gardou@laposte.net Date: Mon, 23 Feb 2009 09:35:13 +0100 Subject: [PATCH] faultrep: Make ReportFault do something useful MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1.6.0.6"
This is a multi-part message in MIME format. --------------1.6.0.6 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit
--- dlls/faultrep/faultrep.c | 7 ++++++- dlls/kernel32/except.c | 2 +- dlls/kernel32/kernel32.spec | 3 +++ 3 files changed, 10 insertions(+), 2 deletions(-)
--------------1.6.0.6 Content-Type: text/x-patch; name="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="8d94c4a333f90cc2be6c9019f84ccc7712b5a0b2.diff"
diff --git a/dlls/faultrep/faultrep.c b/dlls/faultrep/faultrep.c index d4bd713..bb896f9 100644 --- a/dlls/faultrep/faultrep.c +++ b/dlls/faultrep/faultrep.c @@ -37,6 +37,7 @@ static const WCHAR SZ_EXCLUSIONLIST_KEY[] = { 'E','r','r','o','r','R','e','p','o','r','t','i','n','g','\', 'E','x','c','l','u','s','i','o','n','L','i','s','t', 0};
+ /************************************************************************* * AddERExcludedApplicationW [FAULTREP.@] * @@ -107,7 +108,11 @@ BOOL WINAPI AddERExcludedApplicationA(LPCSTR lpAppFileName) */ EFaultRepRetVal WINAPI ReportFault(LPEXCEPTION_POINTERS pep, DWORD dwOpt) { - FIXME("%p 0x%x stub\n", pep, dwOpt); + LONG ret ; + TRACE("%p 0x%x stub\n", pep, dwOpt); + + ret = wine_start_debugger_atomic(pep) ; + return frrvOk; }
diff --git a/dlls/kernel32/except.c b/dlls/kernel32/except.c index 21d3584..f471e05 100644 --- a/dlls/kernel32/except.c +++ b/dlls/kernel32/except.c @@ -347,7 +347,7 @@ EXIT: * * returns TRUE for the two first conditions, FALSE for the last */ -static int start_debugger_atomic(PEXCEPTION_POINTERS epointers) +int CDECL start_debugger_atomic(PEXCEPTION_POINTERS epointers) { static HANDLE hRunOnce /* = 0 */;
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec index b0f4ee7..e5e79c3 100644 --- a/dlls/kernel32/kernel32.spec +++ b/dlls/kernel32/kernel32.spec @@ -1264,3 +1264,6 @@
# Init code @ cdecl __wine_kernel_init() + +#debugging +@ cdecl wine_start_debugger_atomic(ptr) start_debugger_atomic
--------------1.6.0.6--