Wrong exception location in minidump

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Crash the program built with the attached source file.
2. Examine the minidump.

What is the expected output? What do you see instead?
The minidump shows the exception location is at the `func1()` in
`wWinMain()`, whereas the actual location happens at `pB->pA->Print();` in
`func2()`.

What version of the product are you using? On what operating system?
1.2.2, Windows 7.

Please provide any additional information below.
The code is based on the figure 5 in
http://www.debuginfo.com/articles/effminidumps.html. While the exception
location is still correct, it provides little information to developer. All
stack data seem lost, no matter what minidump type is specified.

If I use SEH __try __except directly, the minidump shows the correct
location. When MiniDumpWithIndirectlyReferencedMemory is specified, all
stack data are also preserved.

There are some other issues. If I do not want to include any privacy
policy, and set pszPrivacyPolicyURL to NULL, CrashSender crashes. The
Release LIB configuration seems quite obsolete. How about removing it from
the release version? The documentation also needs update. Without looking
into the CrashRptTest project, I will never notice the CrAutoInstallHelper
object. Directly calling InstallW simply does not work.

BTW, is it possible to build crashrpt into application exe/dll? Is there
problem if my application exe/dll requires the /MT flag? Does
"CRASHRPT_LIB" do anything about this?

Thanks!

Original issue reported on code.google.com by crendk...@gmail.com on 5 Apr 2010 at 3:45

[GoogleCodeExporter]

Here's the code.

Forget to mention, if pszDebugHelpDLL is NULL (as CrashRptTest shows), even
dbghelp.dll is in the System32 directory (shipped with Windows 7), the minidump 
are
not generated (the LoadLibrary at line 331 returns NULL). If I copy dbghelp.dll 
to
the same directory as CrashSender.exe, everything is OK.

Original comment by crendk...@gmail.com on 5 Apr 2010 at 3:52

Attachments:

• crash_test.cpp

[GoogleCodeExporter]

Please create new issue per each detected bug. It will simplify tracking 
changes. 

Original comment by zexspect...@gmail.com on 6 Apr 2010 at 6:24

[GoogleCodeExporter]

As you wish.

Original comment by crendk...@gmail.com on 7 Apr 2010 at 12:49

[GoogleCodeExporter]

I managed to discover that the Debug configuration works fine. Then I narrow 
down the
difference from the Release configuration, and found that if any optimization is
turned on (other than /Od), the location was wrong. Is this a known issue? The
performance might deteriorate tremendously if optimizations are forced to 
disable,
and force me to release a debug version separately.

Original comment by crendk...@gmail.com on 7 Apr 2010 at 5:21

[GoogleCodeExporter]

BugTrap has the same behavior.

Original comment by crendk...@gmail.com on 7 Apr 2010 at 5:38

[GoogleCodeExporter]

Original comment by zexspect...@gmail.com on 8 Apr 2010 at 7:16

• Changed state: Accepted

[GoogleCodeExporter]

So, the reason is in optimizations? Not in CrashRpt bug? If so, there is 
nothing to
fix here.

I suppose optimizations really can affect the minidump generation. For example, 
if
you try to debug the Release build in Visual Studio, you can see that 
optimizations
affect the accuracy of the debugger. The same way the optimizations may affect 
the
minidump.

Original comment by zexspect...@gmail.com on 10 Apr 2010 at 12:37

[GoogleCodeExporter]

The problem seems to be caused by program optimizations, not by bug in 
CrashRpt. 

Original comment by zexspect...@gmail.com on 14 Apr 2010 at 10:34

• Changed state: WontFix