Impossible to send Crash reports in Windows 7 64bits

[GoogleCodeExporter]

On Windows XP 32bits the crash report is generated and sent to my server. The 
same 32 bits executable ran on a Windows 7 64 bits never show the crash report 
window and never sends the report. Though the files can be found (sometimes 
they are NULL-size) in the AppData directory...
I compiled the crashsender.exe and CrashRpt lib with MD option.

I'm using the 1.2.10 version of CrashRpt.

I have no crash nor error, nothing simply happens.

Otherwise I tried to link the application crashsender and the lib using the MT 
flag. I runs fine in Windows 7 64 bits but there, the crashsender.exe crashes 
with an error .

Could someone help me ?

Regards

Original issue reported on code.google.com by ha...@hadop.fr on 19 Aug 2011 at 8:20

[GoogleCodeExporter]

Does your application requires administrative privilegies?

Original comment by zexspect...@gmail.com on 20 Aug 2011 at 2:05

• Changed state: Reviewed

[GoogleCodeExporter]

No it does not.
Here is what I just tried :
Put the CrasrptTest.exe in a folder. When I start it it complains about the 
Crashrpt.dll. I put the dll. I start it. It complains about the 
Crashsender.exe. I put it... and so until the language file. When all files are 
there I start the CrashrptText and nothing happens. Not even a message.
On Windows XP it works perfectly.

Original comment by ha...@hadop.fr on 20 Aug 2011 at 7:49

[GoogleCodeExporter]

I have to say that I tried to supress the manifest file from crashsender.exe 
project and rebuild and it didn't change

Original comment by ha...@hadop.fr on 20 Aug 2011 at 8:03

[GoogleCodeExporter]

Please clarify this moment: in Windows 7 x64, does CrashRptTest.exe starts and 
displays its main window? Or the process just imediatelly exits silently 
without displaying the main window?

Original comment by zexspect...@gmail.com on 20 Aug 2011 at 11:21

[GoogleCodeExporter]

The crashrpttest.exe doesn't even show its main window. I suppose it exits 
silently.

Original comment by ha...@hadop.fr on 20 Aug 2011 at 12:10

[GoogleCodeExporter]

1. Open CrashRpt solution and set CrashRptTest the startup project. 
2. Place a breakpoint in CrashRptTest.cpp line 113 (in the beginning of 
_tWinMain() function). 
3. Press F5 to run the program. 
4. Press F10 several times to debug the program in step-by-step mode. 

What do you see? Where does the program exits?

Original comment by zexspect...@gmail.com on 20 Aug 2011 at 5:06

[GoogleCodeExporter]

Here is the result :
All is ok until the line 209 where the app stops without error message; But in 
the console there is :
Exception de première chance à 0x007741b0 dans CrashRptTestd.exe : 
0xC0000005: Access violation.
Le thread 'CrashThread' (0x7b4) s'est arrêté avec le code 1 (0x1).
Le programme '[2244] CrashRptTestd.exe: Natif' s'est arrêté avec le code 1 
(0x1).

Original comment by ha...@hadop.fr on 29 Aug 2011 at 12:37

[GoogleCodeExporter]

Please notice that if I uncompress the 7z archive and execute the 
CrashRptTest.exe included in the distribution it works. 
It stops working when I compile it by myself...

Original comment by ha...@hadop.fr on 29 Aug 2011 at 12:46

[GoogleCodeExporter]

I can't see the reason for now, I need more information. You need to step into 
the Run() function and see what hapens there (use F11 to step into). 

Original comment by zexspect...@gmail.com on 29 Aug 2011 at 1:50

[GoogleCodeExporter]

Ok sorry, I thought Run() was inside a MS lib.

Now I can see it crashes at line 88. When I step into I can see it crashes on 
the assertion on hWnd is not null... Weird.

Original comment by ha...@hadop.fr on 29 Aug 2011 at 2:31

[GoogleCodeExporter]

By some strange reason the MainDlg fails to create itself. This may be related 
to manifest issues, but I'm not sure. 

What version of Visual C++ do you use?

Original comment by zexspect...@gmail.com on 31 Aug 2011 at 3:55

[GoogleCodeExporter]

I'm using visual c++ 2010 express with platform sdk.

Original comment by ha...@hadop.fr on 31 Aug 2011 at 4:05

[GoogleCodeExporter]

Please clarify: Does CrashRptTest not start or does CrashSender (the one that 
actually sends the report) not start?
Does it only concern win32 builds on x64 systems?
In all this is true, please test whether the it concerns only SEH and c++ 
exceptions or whether it is also true for the signal and terminate handlers. If 
it only applies to the exceptions, it is the normal behavior which is due to a 
known issue: 

On 64bit systems running a 32bit application the process will usually swallow 
exceptions behind a window callback. This is a windows bug which may stay in 
place because it has been there for a long time. See Microsoft KB 976038 
(http://support.microsoft.com/kb/976038) and this formum post 
(http://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exce
ptions-on-x64-machines-are-silently-caught-in-wndproc-messages) for details.

Enabling the hotfix will cause the crash to occur. I have attached a file 
implementing a function crEnableProcessCallbackFilter(BOOL bEnable). Call 
crEnableProcessCallbackFilter(FALSE) in your program and it will crash 
faithfully.

A remark: Even with the hotfix enabled, exceptions are still not propagated 
upwards i.e. the program will crash even if there is a catch() clause in place 
outside the window procedure. 
This quite annoying problem can only be solved by hooking the window procedure 
and placing catch statements there. Maybe more on that later in context with a 
CrashRpt version that allows program continuation after non-fatal crashes.

Original comment by Schoenle...@googlemail.com on 20 Sep 2011 at 8:57

Attachments:

• callback_filter.cpp

[GoogleCodeExporter]

oops, sorry. I just re-read and it seems that quite clearly the test 
application causes the problems. 
My comment does not apply to your issue then, sorry about that.

Original comment by Schoenle...@googlemail.com on 20 Sep 2011 at 9:04

[GoogleCodeExporter]

I coldn't reproduce this with v.1.2.10. Can you try new v.1.3.0 and tell me if 
this still can be reproduced?

Original comment by zexspect...@gmail.com on 22 Oct 2011 at 11:06

[GoogleCodeExporter]

Closing the issue, because there is no responce from the reporter.

Original comment by zexspect...@gmail.com on 6 Nov 2011 at 4:39

• Changed state: WontFix

[GoogleCodeExporter]

Hi,

I'm in the process of integrating CrashRpt into our MFC based software. It is 
an amazing library and very easy to use, kudos!

However, I just spent the past few days figuring out why some crashes were not 
triggering the crash report dialog. Also, when the dialog was triggered, the 
stack trace of the crash dump was bogus. I finally came across this page 
(http://code.google.com/p/crashrpt/issues/detail?id=104) where a user mentions 
that this is a problem for win32 applications on x64 systems. The workaround 
posted by the user completely solved my problems. I just added a call to 
SetProcessUserModeExceptionPolicy disabling PROCESS_CALLBACK_FILTER_ENABLED, 
and now the crash reporting works properly and the stack traces look correct.

I think it might be a good idea to add this to future versions of CrashRpt, 
either automatically disable process callback filter or add it as an option. It 
might also be a good idea to update the FAQ with that information as well.

Cheers,
Farshid

Original comment by zexspect...@gmail.com on 11 May 2012 at 3:17

• Changed state: Accepted

[GoogleCodeExporter]

I added the code that calls SetProcessUserModeExceptionPolicy() with 
PROCESS_CALLBACK_FILTER_ENABLED flag. Hope this helps.

Fixed in rev. 1324 of trunk.

Original comment by zexspect...@gmail.com on 16 Aug 2012 at 4:12

[GoogleCodeExporter]

Original comment by zexspect...@gmail.com on 16 Aug 2012 at 4:12

• Changed state: Fixed