Running crprober on windows 7 results in no stack trace output

[GoogleCodeExporter]

***NOTE*** Please do create a NEW issue per each detected bug! Do not list
all detected problems in single issue record!

What steps will reproduce the problem?
1. Create a crash report
2. run crprober specifying the symbols and crash report
e.g. crproberd.exe /f D:\temp\crash-test.zip /o "" /sym "D:\project\test

What is the expected output? 

After the file list there should be a stack trace:
e.g. 
== Stack trace for thread 0x19c4 ==

Frame
KERNELBASE.dll!0x76fcc41f

What do you see instead?
No stack frame is listed and the symbol status list is empty

What version of CrashRpt are you using?
1.3.0

What is your version of Visual Studio?
2008

What is your version of Windows operating system?
windows 7 professional - separate temp partition - corporate build with various 
"security enhancements" which I'm probably not allowed to know about.

Please provide any additional information below.
CMiniDumpReader::Open(CString sFileName, CString sSymSearchPath)
line 97 calls CreateFile with the parameter FILE_ALL_ACCESS
This fails it appears that the flag FILE_DELETE_CHILD is the problem and the 
following works: (FILE_GENERIC_READ | FILE_GENERIC_WRITE | FILE_APPEND_DATA | 
FILE_EXECUTE)

Propose that FILE_GENERIC_READ should be sufficient though (FILE_GENERIC_READ | 
FILE_GENERIC_WRITE) works fine as well.

Original issue reported on code.google.com by martinsi...@gmail.com on 2 Jan 2013 at 3:57

[GoogleCodeExporter]

Could I also suggest we output a warning when the file open fails.
The code tests for it immediately after the CreateFile call and there are a 
list of reported statuses to the calling code 
crashRptProbe::crpGetPropertyW line 572 which are all ignored.
They should probably be converted into enums and reported.

Original comment by martinsi...@gmail.com on 2 Jan 2013 at 4:21

[GoogleCodeExporter]

Issue 181 has been merged into this issue.

Original comment by zexspect...@gmail.com on 5 Jan 2013 at 8:02

[GoogleCodeExporter]

I modified the code of CMiniDumpReader::Open() method, so now it should open 
the file with correct access mode. I also added a check of Open()'s return code 
to return an error message if minidump cannot be opened. You can checkout the 
latest code from trunk. 

Original comment by zexspect...@gmail.com on 6 Jan 2013 at 4:42

[GoogleCodeExporter]

This issue was closed by revision r1495.

Original comment by zexspect...@gmail.com on 6 Jan 2013 at 4:42

• Changed state: Fixed