rdmenezes / crashrpt Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/crashrpt
Automatically exported from code.google.com/p/crashrpt
The Release exe file compressed with PECompact (probably other compressors
also) doesn show the line where the program crushes. Normal exe show the
line, but when I compress it with PECompact id doesnt.
I tried to run the dump file with compresed exe, and uncompresed but in
eihter cases it doesn show the error line.
Im using CrachRpt 1.2.4
How can CrachRpt and PECompact work together?
Original issue reported on code.google.com by [email protected]
on 26 May 2010 at 11:16
Steps for reproducing the problem
1.Compile CrashRpt in VS2008Express Edition
2.getting crash.dmp(Structred Exception)
std :: vector<int> a;
int m = a.at(0);
3.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 3 May 2010 at 2:08
What steps will reproduce the problem?
1. Cause an error report.
2. Open the details dialog.
3. Pay attention to the contained file sizes being listed in bytes.
What is the expected output? What do you see instead?
The sizes are listed in bytes, but with a KB unit.
What version of the product are you using? On what operating system?
CrashRpt 1.2.0 r475 on Windows 7.
I suggest replacing the commented line below, with the following change to
DetailDlg.cpp
//sSize.Format(TEXT("%d KB"), findFileData.nFileSizeLow);
double fFileSizeBytes = findFileData.nFileSizeLow;
_STPRINTF_S(sSize.GetBufferSetLength(20), 20, _T("%.2f KB"), fFileSizeBytes
/ 1024);
... along with this addition to stdafx.h in crashsender:
For _MSC_VER < 1400:
#define _STPRINTF_S(strDest, sizeInChars, strSource, args)
_stprintf(strDest, strSource, args)
... and otherwise:
#define _STPRINTF_S(strDest, sizeInChars, strSource, args)
_stprintf_s(strDest, sizeInChars, strSource, args)
Sorry for not submitting this as a code review, but I got confused over how
to set the entry about "/branches".
Original issue reported on code.google.com by [email protected]
on 11 Dec 2009 at 11:07
at CCrashHandlerEx::GenerateCrashDescriptorXML in CrashHandler.cpp
// Add <?xml version="1.0" encoding="utf-8" ?> element
fprintf(f, "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n", CRASHRPT_VER);
maybe, CRASHRPT_VER is not necessary at fprintf param.
thank you.
Original issue reported on code.google.com by [email protected]
on 18 Feb 2010 at 4:36
What steps will reproduce the problem?
1. click the link: http://www.microsoft.com/ddk/debugging/default.asp
What is the expected output?
--> win
What do you see instead?
--> fail
Original issue reported on code.google.com by [email protected]
on 23 Jul 2010 at 8:51
***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.
in CrashRpt.cpp
line 51:
nResult = crAddRegKey(_T("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer"), _T("regkey.xml"), 0);
ATLASSERT(nResult==0);
2.
F11 step : nResult = 2
3.
What is the expected output? What do you see instead?
F11 step : nResult = 0
What version of the product are you using? On what operating system?
1.2.6 , xp
Please provide any additional information below.
In CrashRpt.cpp line 463
the "return crAddRegKeyW(strconv.a2w(pszDstFileName),
strconv.a2w(pszRegKeyList), dwFlags);" maybe the first param is
"pszRegKeyList",the second is "pszDstFileName"
Original issue reported on code.google.com by [email protected]
on 10 Aug 2010 at 9:19
Shouldn't CCrashHandler::m_ThreadExceptionHandlers be protected with a
critical section?
Original issue reported on code.google.com by [email protected]
on 18 Dec 2009 at 6:54
CrashRpt.dll (v1.2.1) genarates xml "Crash Log" with encoding specified utf-8,
however
CrashSender.exe updates xml by <ProblemDescription> tags and the problem
description
string encoded with ANSI. After that when I open xml in for example IE, I get
something
like that:
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then
click
the Refresh button, or try again later.
An invalid character was found in text content. Error processing resource
'file:///C:/Documents and Settings/mike/Local Set...
<ProblemDescription>
As I realize the problem is that tinixml used in CrashSender.exe writes data
only in
ANSI encoding. For my private usage I replaced the utf-8 specification on an
appropriate system code page. See the attached report.
Original issue reported on code.google.com by [email protected]
on 3 Mar 2010 at 7:46
Attachments:
Add support for screenshots for each monitor (some systems have more than 1
monitor) that are included in the archive at the time of crash. bugtrap has
such support and I found it very useful.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 5:10
I am trying to compile crashrpt using microsoft visual c++ 2008 SP1
express. It seems that you use ATL, and it's not include in the express
edition. Is there any way to bypass ATL. Express version is now widely used
because it's free :), is it possible to support this version?
Original issue reported on code.google.com by [email protected]
on 28 Jul 2009 at 9:10
Current interface is C++. It is more usable if compiled as a straight
WINAPI C-dll. Then it can be used from other languages like VB or .net
projects.
Original issue reported on code.google.com by [email protected]
on 15 Aug 2009 at 2:43
1.when I compiler in mfc application project. I can find out where error line
in source code and get some detail about the error info like this page
http://crashrpt.sourceforge.net/docs/html/using_minidump.html[^]
2.when i compiler in console application project. I can't find out the error
line in source code.
I just get the error reason like Integer division by zero.
3.can crashrpt use on console application project?
Crashrpt Version is : 1.2.4
Original issue reported on code.google.com by [email protected]
on 21 Jun 2010 at 3:01
What steps will reproduce the problem?
1. The crInstall() is called in a main application, which loads several other
DLLs upon start.
2. If a crash occurs in main application, CrashSender.exe sends error report
via email once. Everything works as expected.
3. If a crash occurs occurs in a DLLs, CrashSender.exe is invoked twice to send
the same error report. The second report has an empty zip file although its
UUID and MD5 are same as the other one.
What is the expected output? What do you see instead?
CrashSender.exe should be invoked only once no matter the crash occurs in main
application or its depended DLL
What version of the product are you using? On what operating system?
v1.2.4_r717 XP Home SP3
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 25 Jun 2010 at 6:49
What steps will reproduce the problem?
1. Install crashrerpt on my application, leaving pszRestartCmdLine NULL
2. Crash application
3. Select restart application with the crashrpt UI.
4. Notice that when the application restarts, QApp->argc() returns 2 with an
empty second argument.
I expected the argument count to be 1.
I am using Windows 7, VS 2008 with Qt 4.5.2
Original issue reported on code.google.com by [email protected]
on 30 Aug 2010 at 2:50
Attached there is a patch that have 2 things:
1. Projects for VS 2010. These assume WTL80 is installed in the same folder
as crashrpt, ('crashrpt\src\WTL80\include' exits). It is needed because in vs
2010 (the beta at least) the include settings for VC++ are per project too.
2. 3 new crash types for crEmulateCrash: one that throws an uncaught
exception, one that rethrows it and one that catchs it. The last one is more
like a test that this lib does not do something in that case.
Thanks,
Pescuma
Original issue reported on code.google.com by pescuma
on 1 May 2010 at 5:32
Attachments:
***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. Set pszPrivacyPolicyURL to NULL when installing exception handler with
CrAutoInstallHelper.
2.
3.
What is the expected output? What do you see instead?
There is no privacy policy in the report window.
crashrpt crashes.
What version of the product are you using? On what operating system?
1.2.2, Windows 7.
Please provide any additional information below.
Consider this as an enhancement. People may need more customization in the
report window.
Original issue reported on code.google.com by [email protected]
on 7 Apr 2010 at 12:35
When using VC6 then the exception model requires one to use things like
(Compiler option /EHa is on by default):
_set_se_translator(CrashReport::SEH_Translator);
::SetUnhandledExceptionFilter(CrashReport::ReportCrash);
But when using VC7 / VC8 then one should use __try / __except (Compiler
option /EHs is on by default).
Therefore it should be up to the application itself to decide how to
install the handler. This would also make it easier for the application to
decide what should happen in the handler (besides sending a crash report).
Also it would be nice if the interface for collecting the report items
(screendump, minidump, xml-report,etc.), was seperated from building the
report zip-file (AddFile, AddRegistry, etc.). This would allow the
application it self to add own temporary report items and delete them
after the crash-report was done.
Also it would be nice that the CrashRptDL.h was a wrapper class around the
HMODULE handle and it had the necessary funktions to:
- Create report items.
- Build the report zip-file.
- Send / Save the report zip-file.
Will try to create an example of what I was thinking this coming weekend.
Original issue reported on code.google.com by sweaty1
on 10 May 2007 at 9:08
1. after building in VS.NET and running:
crprober.exe /f E:\1\3dae14ed82274a63aad8fad49c10b7c9.zip /o "" /sym
E:\temp\\af\bindebug -> exit with an error
crprober -> main.cpp
...
// Decide input dir and file name
sInDirName = szInput;
size_t pos = sInDirName.rfind('\\');
if(pos<0) // There is no back slash in path
{
sInDirName = _T("");
sInFileName = szInput;
}
else
{
sInDirName = sInFileName.substr(0, pos);
sInFileName = sInFileName.substr(pos+1); << crashed here!!!
}
...
2. I can't obtain file list from crashrpt.xml. It's empty in my report:
== File list ==
# Name Description
?????
Although crashrpt.xml contains it, see:
<FileItems>
<FileItem name="AF.log" description="ActualFlow Log File" />
<FileItem name="crashdump.dmp" description="Crash Dump" />
<FileItem name="crashrpt.xml" description="Crash Log" />
</FileItems>
Original issue reported on code.google.com by [email protected]
on 2 Mar 2010 at 6:35
Purpose of code changes on this branch:
Additions/Fixes
When reviewing my code changes, please focus on:
-fix: Ambiguity of WTL::CString and ATL::CString. I Replaced <atlmisc.h>
with <atlstr.h> and <atltypes.h>
where needed (in many places).
-add: C++ exception handlers (CrashHandler.cpp).
Some handlers are installed on per-process basis (add
SetProcessCPPExceptionHandlers()\UnSetProcessCPPExceptionHandlers())
and some on per-thread basis
(SetThreadThreadCPPExceptionHandlers()\UnSetThreadThreadCPPExceptionHandlers()).
-add: Two new exported functions: crInstallToCurrentThread() and
crUninstallFromCurrentThread().
These functions install/uninstall C++ exceptions on per-thread basis.
'cr' prefix means 'crashrpt'. I offer to add 'cr' to all new
functions that we create for crashprt.
-add: <MiscInfo> tag in XML file. The tag contains UserEmail,
ProblemDescription and SystemTime attributes.
This is to make more convenient to analyse crash reports on
developer's side.
-add: Modified CRASHRPT_EXPORTS definition (I had some problems with it).
Added CRASHRPT_EXPORTS preprocessor definition in project settings.
This way is recommended in MSDN.
-fix: Replaced LPCSTR with LPCTSTR everywhere. This is to correctly support
UNICODE.
-add: Window icon (maindlg.h: line 119). Set last param to FALSE to load
small icon.
-fix: Last character in email becomes lost (maindlg.h: line 190). I added
+1 to length of buffer.
After the review, I'll merge this branch into:
/trunk
Original issue reported on code.google.com by [email protected]
on 13 May 2009 at 12:30
Allow the end-user to select via the crash dialog which level of mini dump
to generate. I suggest offering 3 different levels. 1) small mini dump
consisting of MiniDumpNormal, 2) medium size mini dump consisting of the
following options: MiniDumpWithPrivateReadWriteMemory,
MiniDumpWithDataSegs, MiniDumpWithHandleData, MiniDumpWithFullMemoryInfo,
MiniDumpWithThreadInfo, MiniDumpWithUnloadedModules 3) full size dump of
entire address space consisting of the following options:
MiniDumpWithFullMemory, MiniDumpWithFullMemoryInfo, MiniDumpWithHandleData,
MiniDumpWithThreadInfo, MiniDumpWithUnloadedModules
The UI should support selection between one of the 3 option types. In fact,
I would suggest only offering selection between option 2 and option 3.
Next, allow the programmer to specify a custom path/filename to dbghelp.dll
- This is necessary because some of the MINIDUMP_TYPE options are not
available in older versions of dbghelp.dll - I ship dbghelp.dll with my
app, but unless I can specify a path/filename to dbghelp.dll then there is
chance that an older version already installed on the end-user's PC will be
installed. So please allow for the programmer to specify a custom string to
indicate which file to load. NOTE: this means that CrashRpt cannot link to
dbghelp.lib - Instead LoadLibrary(...) and GetProcAddress(...) must be called.
I have attached example code to illustrate what I mean. This code is meant
to serve as an nothing more than a working example and not meant to dictate
API structure, etc. - In the attached files note the use of
LoadLibrary(...), GetProcAddress(...), g_sDebugHelpDllFile, g_MiniDumpType,
etc.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 6:48
Attachments:
What steps will reproduce the problem?
1. download latest source
2. open CrashRpt_vs2005.sln (it will convert via wizard)
3. compile
What is the expected output?
--> success compiling
What do you see instead?
1>------ Build started: Project: CrashRpt, Configuration: Debug Win32 ------
1>Compiling...
1>CrashHandler.cpp
1>...\crashrpt\src\CrashHandler.cpp : fatal error C1001: An internal error
has occurred in the compiler.
1>(compiler file
'f:\dd\vctools\compiler\utc\src\p2\main.c[0x70387740:0x0000000C]', line 182)
1> To work around this problem, try simplifying or changing the program
near the locations listed above.
1>Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
What version of the product are you using? On what operating system?
latest
windows vista
Please provide any additional information below.
i was going to use this, but, well, doesn't look like i can.
Original issue reported on code.google.com by [email protected]
on 12 Apr 2010 at 5:45
Please add support for the following:
* computer name (NetBIOS name)
* ip address of the PC
* additional information about the PC hardware such as number of CPUs,
type, amount of RAM installed as well as how much memory the process was
using at the time of crash. Also, if possible - would be very useful to
know the type of video card installed as well as the driver version of that
video card.
* total amount of disk space that and free disk space
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 5:37
***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. Try to build crashrpt with the Release LIB configuration
2.
3.
What is the expected output? What do you see instead?
crashrpt.lib is generated, which can be linked into the target module.
Build fails with numerous errors and missing files.
What version of the product are you using? On what operating system?
1.2.2, Windows 7.
Please provide any additional information below.
Obviously the Release LIB configuration is quite obsolete, telling from the
include directory list. How about removing it? In the FAQ
(http://code.google.com/p/crashrpt/wiki/FAQ), it is clearly stated:
Can I compile crashrpt as a static library?
No, currently you can't do this.
I think this configuration would mislead crashrpt users.
Original issue reported on code.google.com by [email protected]
on 7 Apr 2010 at 12:39
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 [email protected]
on 5 Apr 2010 at 3:45
It will be great to have the opportunity to set screenshot capture,
sometimes it worth more then user description to understand what's happen.
Original issue reported on code.google.com by [email protected]
on 16 Mar 2010 at 10:14
SmtpClient.cpp shoud be
int CSmtpClient::GetSmtpServerName(..)
{
...
if(r==0)
{
PDNS_RECORD pRecOrig = apResult;
while(apResult!=NULL)
{
if(apResult->wType==DNS_TYPE_MX)
{
CString sServerName = CString(apResult->Data.MX.pNameExchange);
host_list[apResult->Data.MX.wPreference] = sServerName;
}
apResult = apResult->pNext;
}
DnsRecordListFree( pRecOrig, DnsFreeRecordList);
return 0;
}
...
}
buffer returned from dns query must be released and since apResult is NULL
after evaluation a copy of the original pointer must be saved and passed to
DnsRecordListFree(..)
Original issue reported on code.google.com by [email protected]
on 21 Jun 2010 at 6:57
I think it should be used in thread level rather than application.
First:CrashHandler map in CrashRpt.DLL will not share with multi-process.Every
Application(process) has a CrashHandler map itself.
Second:The MSDN (See http://msdn.microsoft.com/en-
us/library/ms680634(VS.85).aspx)says:"Issuing SetUnhandledExceptionFilter
replaces the existing top-level exception filter for all existing and all
future threads in the calling process.",which means SetUnhandledExceptionFilter
is a thread-concerned function.
Forgiven my English.
Original issue reported on code.google.com by [email protected]
on 8 Sep 2009 at 2:53
I would find it useful if the folder where crash reports will be created
could be specified by the application, perhaps using a new setting in the
CR_INSTALL_INFO structure. We have an application that runs as a service and
we would always like crash reports created in the same folder as the EXE, as
it makes them much easier to find.
Original issue reported on code.google.com by [email protected]
on 10 Mar 2010 at 7:14
Add support for a failure mode such that CrashRpt will automatically submit
a report without the need for an end-user to intervene and click any sort
of submit button. This feature is useful for server processes.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 6:58
***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.compile ur application with crash report build in.
2. Don't set the version number. let crash report retrieve from module.
3a. It will crash if you don't specify any version information for the module.
3b. If the version number is greater than 3 digits, it will retrieve wrong
number. For example: 0.8.1.1444, it will only retrieve 0.8.144 or something
similar.
What is the expected output? What do you see instead?
See: 3a - crash
3b - incorrect version number.
Expected:
3a - not crash
3b - and retrieve the correct version number.
What version of the product are you using? On what operating system?
OS: vista bussiness 32bit
crashrpt: v1.2.4_r717
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 8 Aug 2010 at 11:37
feature request for x64 support
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 5:09
***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. Install the exception handler with InstallW, as guided in the CrashRpt
v1.0 Documentation.
2. Trigger an exception.
3. Run the output program.
What is the expected output? What do you see instead?
The report window pops up.
CrashSender.exe crashes.
What version of the product are you using? On what operating system?
1.2.2, Windows 7.
Please provide any additional information below.
crashrpt works OK if I switch to install the exception handler with
CrAutoInstallHelper, as what crashrpttest does. Another proof of InstallW's
obsoleteness is in CrashRptTest.cpp, where the calling of Install() is
guarded by a preprocessor TEST_DEPRECATED_FUNCS. Seems the documentation
really needs update.
Original issue reported on code.google.com by [email protected]
on 7 Apr 2010 at 12:48
What steps will reproduce the problem?
1. Translate CrashRpt via the ini file.
2. Cause an error to be caught.
3. Open the details dialog box and notice the Close button always says
"Close".
What is the expected output? What do you see instead?
That the close button supports localization.
What version of the product are you using? On what operating system?
CrashRpt 1.2.0 r475 on Windows 7.
Original issue reported on code.google.com by [email protected]
on 11 Dec 2009 at 11:12
Users with Windows 2000 report that CrashRpt fails on their system.
There is a missing dependency to GetProcessHandleCount function in
kernel32.dll.
GetProcessHandleCount fuction is supported only Windows XP with SP1 or
newer.
Anything you can do about this?
Original issue reported on code.google.com by [email protected]
on 4 Jan 2010 at 1:41
***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. view documentation here:
http://code.google.com/p/crashrpt/wiki/CrashRpt_v1_0_Documentation
2. scroll down to "Using the Crash Log"
3. look at pictures
What is the expected output?
something like the pictures
What do you see instead?
<?xml version="1.0" encoding="UTF-8" ?>
<CrashRpt version="1205">
<CrashGUID>2dc7d88d-4afb-4a5a-a67a-406f1a875cb8</CrashGUID>
<AppName>kJams Pro</AppName>
<AppVersion>1.0d51r10</AppVersion>
<ImageName>C:\Users\Owner\Desktop\kJams Pro.app\Contents\Windows\kJams Pro.exe</ImageName>
<OperatingSystem>Windows 7 Home Premium Build 7600</OperatingSystem>
<SystemTimeUTC>2010-07-23T20:26:53Z</SystemTimeUTC>
<ExceptionType>0</ExceptionType>
<ExceptionCode>0xC0000005</ExceptionCode>
<GUIResourceCount>249</GUIResourceCount>
<OpenHandleCount>467</OpenHandleCount>
<MemoryUsageKbytes>143872</MemoryUsageKbytes>
<CustomProps />
<FileList>
<FileItem name="Log_File.txt" description="Log File" />
<FileItem name="crashrpt.xml" description="Crash Log" />
<FileItem name="crashdump.dmp" description="Crash Dump" />
</FileList>
<UserEmail></UserEmail>
<ProblemDescription></ProblemDescription>
</CrashRpt>
note what is missing:
module name
description
architecture
num of processors
operating system
etc
What version of the product are you using?
latest
On what operating system?
random depending on user
Original issue reported on code.google.com by [email protected]
on 23 Jul 2010 at 8:49
Steps for reproducing the problem
1.Compile CrashRpt in VS2008Express Edition
2.getting crash.dmp(Structred Exception)
std :: vector<int> a;
int m = a.at(0); //Structred Exception Handler (SEH) called
get a crash.dmp
3. Debug crash.dmp using VS2008Express Edition , Here StackTace are not
showing proper but same crash.dmp VS2005 showing prper stack where
execption had happened
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 3 May 2010 at 2:11
if the user does not have write access to the application folder, then the
current method of "copy in the correct language file" will fail. there
needs to be a way to specify the path to the language file instead, and
have that be used
What steps will reproduce the problem?
1. lock the folder of the app, or put it on a read only server
2. launch
3. the "langage file copy" operation fails
4. look for a sanctioned method to specify lang file path
5. weep in dispair
What is the expected output?
--> an API for this
What do you see instead?
--> no API
What version of the product are you using?
v.1.2.3
On what operating system?
Windows 7 + latest updates
Please provide any additional information below.
--> could be specify the path in the param block, or a callback function.
i prefer a callback function
if you do this for me, i will provide French, German, Japanese, Italian,
Spanish, Portuguese, possibly Chinese, Thai and Korean translations
Original issue reported on code.google.com by [email protected]
on 20 Apr 2010 at 11:25
Add an option that allows for CrashRpt to auto-restart a failed process.
There should be some sort of configurable time out parameter that can
dictate how long CrashRpt should wait before the new process is started.
This option is useful for server processes.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2009 at 6:57
What steps will reproduce the problem?
1. browse documentation for how to send attached files with no crash dump
2. browse documentation for how to send recent crash report (not new one)
3. realize there is no way
What is the expected output?
--> an API for these functions
What do you see instead?
--> no API
What version of the product are you using?
--> v.1.2.3
On what operating system?
--> Windows 7 with all updates
Please provide any additional information below.
--> just need a way to say "send this (log) file to the author" or "send
recent crash report" and move it out of the "unsent crashes" folder
Original issue reported on code.google.com by [email protected]
on 19 Apr 2010 at 11:23
***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. Make sure there is no dbghelp.dll in the same directory.
2. Set pszDebugHelpDLL to NULL (as CrashRptTest shows) when installing with
CrAutoInstallHelper.
3. Trigger exception.
4. See if minidump is generated.
What is the expected output? What do you see instead?
Minidump is not generated, given that dbghelp.dll is in the System32
directory (shipped with the system).
What version of the product are you using? On what operating system?
1.2.2, Windows 7.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 7 Apr 2010 at 12:32
What steps will reproduce the problem?
Just send a crash report ( tested Win XP SP3 / Vista SP2 - both Italian)
What is the expected output? What do you see instead?
DateTimes for files generated by CrashSender ( .dmp, .png, .xml ) are
wrong, the same with files copied into report using crAddFile()
What version of the product are you using? On what operating system?
latest (problem was present also in previous versions) 1.24
Please provide any additional information below.
for example a zip file dated 5-22-2010 11:39 have inside files dated 6-22-
2010 09:39. Each files is saved with 1 month added and (i think) in GMT
and not local time ( i suppose this: Italy is -1 TZ and with daylight
saving active )
Original issue reported on code.google.com by [email protected]
on 27 May 2010 at 6:25
If m_pCrash_info->pszUrl is NULL Or = _T( "") (I do not have an upload
site) with m_pCrash_info->uPriorities[CR_HTTP] = 0; CrashSender crashes
while getting url properties.
VS2008 SP1 - C++ - MBCS - Linked libraries with static CRT
Original issue reported on code.google.com by [email protected]
on 5 Apr 2010 at 9:48
1) In httpsend.cpp in the _Send(...) function, there is this code:
if(atoi(szResponce)!=200)
{
an->SetProgress(_T("Failed"), 100, false);
goto exit;
}
I believe this is in error. It is not reliable to expect the first few
characters of a web page to contain the status code. In fact, unless I
comment out the above lines of code the HTTP upload never works. I think
this code can safely be removed. Comments?
2) The current HTTP upload mechanism only supports base64 encoding. This is
problematic when sending large files (when dumping the entire process
memory space for example.) There are a couple of problems with using base64
in conjunction with sending large files: 1) the file has to be base64
encoded first and certain characters have to be replaced. This is extremely
slow on large files. Consider this code:
sPOSTRequest = base64_encode(uchFileData, uFileSize).c_str();
sPOSTRequest = szPrefix + sPOSTRequest + szSuffix;
sPOSTRequest.Replace(_T("+"), _T("%2B"));
sPOSTRequest.Replace(_T("/"), _T("%2F"));
Those Replace(...) function calls are computationally expensive with large
strings. 2) Another issue is server side performance. Presently, when
posting large crash dumps the server has to copy the entire base64 upload
into memory as one contigious block. If several users are posting large
crash dumps this could crash the server due to memory exhaustion.
Multi-part uploads would solve most if not all of these problems.
I would suggest that you investigate using libcurl
http://curl.haxx.se/libcurl/ to post the crash report to the remote server.
Writing the code to perform a multi-part post using libcurl is very
straightforward and fast.
Original issue reported on code.google.com by [email protected]
on 23 Nov 2009 at 11:03
CString CCrashHandler::_ReplaceRestrictedXMLCharacters(CString sText)
{
CString sResult;
sResult = sText;
sResult.Replace(_T("\""), _T("""));
sResult.Replace(_T("'"), _T("'"));
sResult.Replace(_T("&"), _T("&")); // new
sResult.Replace(_T(">"), _T(">")); // new
sResult.Replace(_T("<"), _T("<")); // new
return sResult;
}
Original issue reported on code.google.com by [email protected]
on 15 May 2010 at 10:02
What steps will reproduce the problem?
1. Download the latest distribution
2. Try and build it.
3. It worked for me on Release, but not Debug, I was getting linker errors
on gzclose. When I went looking for gzclose I noticed gzio.c (the file that
contains the body of gzclose was missing.
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
CrashRpt 1.1.3_r416 on Windows
Please provide any additional information below.
downloading the zlib 1.2.3 from zlib.net and putting gzio.c into the
directory made everything work smoothly.
- BTW... Great tool.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2009 at 9:11
What steps will reproduce the problem?
0. Have a global class instance that the main thread uses
1. Install CrashRpt with SEH handler
2. Crash in a different thread
3. CrashRpt calls exit(1) in CCrashHandler::SehHandler, which destructs the
global instance
4. The main thread crashes
Perhaps _exit() should be called instead.
See exit() and _exit() documentation:
http://msdn.microsoft.com/en-us/library/6wdz5232%28VS.90%29.aspx
0:004> ~
0 Id: 260.156c Suspend: 0 Teb: 7ffdf000 Unfrozen
1 Id: 260.16bc Suspend: 0 Teb: 7ffde000 Unfrozen
2 Id: 260.4b0 Suspend: 0 Teb: 7ffdd000 Unfrozen
3 Id: 260.1198 Suspend: 0 Teb: 7ffd9000 Unfrozen
. 4 Id: 260.d8c Suspend: 0 Teb: 7ffdc000 Unfrozen
0:004> ~0s
eax=13421670 ebx=00000000 ecx=00000002 edx=00000000 esi=000000f8 edi=00000000
eip=772164f4 esp=0012f72c ebp=0012f798 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00200246
ntdll!KiFastSystemCallRet:
772164f4 c3 ret
0:000> k
ChildEBP RetAddr
0012f728 77215e6c ntdll!KiFastSystemCallRet
0012f72c 754b179c ntdll!NtWaitForSingleObject+0xc
0012f798 76a9f003 KERNELBASE!WaitForSingleObjectEx+0x98
0012f7b0 76a9efb2 kernel32!WaitForSingleObjectExImplementation+0x75
0012f7c4 10003217 kernel32!WaitForSingleObject+0x12
0012f848 10006265 CrashRpt!CCrashHandler::LaunchCrashSender+0xc9
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @
1347]
0012f87c 1000661e CrashRpt!CCrashHandler::GenerateErrorReport+0x1db
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @
864]
0012f8b4 6ee2cd59 CrashRpt!CCrashHandler::SigsegvHandler+0x45
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @
1667]
0012f8d4 004b8ac5 msvcr90!_XcptFilter+0x151
[f:\dd\vctools\crt_bld\self_x86\crt\src\winxfltr.c @ 375]
0012f8e0 6ee2f594 GME!__tmainCRTStartup+0x18b
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 603]
0012f8f4 6ee3155e msvcr90!_EH4_CallFilterFunc+0x12
0012f920 004b85e1 msvcr90!_except_handler4_common+0x8e
0012f940 772165f9 GME!_except_handler4+0x20
0012f964 772165cb ntdll!ExecuteHandler2+0x26
0012fa14 77216457 ntdll!ExecuteHandler+0x24
0012fa14 0049182a ntdll!KiUserExceptionDispatcher+0xf
0012fd38 00422ae0 GME!CGraphics::Uninitialize+0xa
[e:\gmesrc\trunk\gme\gme\graphicsutil.cpp @ 179]
0012fee4 623e717d GME!CGMEApp::Run+0x180 [e:\gmesrc\trunk\gme\gme\gmeapp.cpp @
538]
0012fef8 004b8a7a mfc90!AfxWinMain+0x6a
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 47]
0012ff88 76aa1174 GME!__tmainCRTStartup+0x140
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
0012ff94 7722b3f5 kernel32!BaseThreadInitThunk+0xe
0012ffd4 7722b3c8 ntdll!__RtlUserThreadStart+0x70
0012ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> ~4s
eax=047bc758 ebx=00000000 ecx=623d9190 edx=000000eb esi=00507108 edi=00507108
eip=6241be18 esp=02eff6a8 ebp=02eff8d8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
mfc90!CWinApp::~CWinApp+0x4a:
6241be18 385814 cmp byte ptr [eax+14h],bl ds:0023:047bc76c=??
0:004> k
ChildEBP RetAddr
02eff8d8 6258a8dd mfc90!CWinApp::~CWinApp+0x4a
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp @ 755]
02eff900 0042f6b8 mfc90!CWinAppEx::~CWinAppEx+0x10a
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxwinappex.cpp @ 131]
02eff91c 6ede23b1 GME!CGMEApp::~CGMEApp+0x1b8
[e:\gmesrc\trunk\gme\gme\gmeapp.cpp @ 150]
02eff960 6ede2466 msvcr90!doexit+0xab
[f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 591]
02eff974 10006348 msvcr90!exit+0x11
[f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c @ 412]
02eff9ac 76ab2c2a CrashRpt!CCrashHandler::SehHandler+0x46
[c:\users\ksmyth\documents\gme\gme\lib\crashrpt\crashrpt\src\crashhandler.cpp @
1391]
02effa34 77245a74 kernel32!UnhandledExceptionFilter+0x127
02effa3c 771ed950 ntdll!__RtlUserThreadStart+0x62
02effa50 771ed7ec ntdll!_EH4_CallFilterFunc+0x12
02effa78 772165f9 ntdll!_except_handler4+0x8e
02effa9c 772165cb ntdll!ExecuteHandler2+0x26
02effb4c 77216457 ntdll!ExecuteHandler+0x24
02effb4c 623d9132 ntdll!KiUserExceptionDispatcher+0xf
02effe80 623d86b4 mfc90!CThreadLocalObject::GetData+0x1f
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxtls.cpp @ 412]
02efff44 6ede3433 mfc90!AfxGetModuleThreadState+0x16
[f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 498]
02efff7c 6ede34c7 msvcr90!_callthreadstartex+0x1b
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
02efff88 76aa1174 msvcr90!_threadstartex+0x69
[f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326]
02efff94 7722b3f5 kernel32!BaseThreadInitThunk+0xe
02efffd4 7722b3c8 ntdll!__RtlUserThreadStart+0x70
02efffec 00000000 ntdll!_RtlUserThreadStart+0x1b
Original issue reported on code.google.com by [email protected]
on 22 Jun 2010 at 4:26
What steps will reproduce the problem?
1. Run CrashSender.exe from a Windows 2000 command prompt
The following error message is displayed:
"The procedure entry point freeaddrinfo could not be located in the synamic
link library WS2_32.dll"
Original issue reported on code.google.com by [email protected]
on 8 Mar 2010 at 3:40
For both the documentation
(http://crashrpt.sourceforge.net/docs/html/exception_handling.html) and the
latest code I see all you do for setting up the exception handler is
SetUnhandledExceptionFilter(). I did some research about exception handling
these days and came across the Vectored Exception Handling
(http://msdn.microsoft.com/en-us/library/ms681420%28v=VS.85%29.aspx). I'm
not quite aware about the difference between the two sets of APIs, but
seems the VEH is more robust and compatible if available, for example you
can remove the handler when DLL is detached from the host process. If there
is no compelling reasons, maybe you can consider adopting VEH in the future
versions.
Original issue reported on code.google.com by [email protected]
on 9 Apr 2010 at 6:53
What steps will reproduce the problem?
1. do a clean build of release, send to tester.
2. tester causes crash, sends crash report back
3. double click .dmp file, it opens new instance VS??
4. what do i do now?
What is the expected output?
--> it will load exe and act like it just crashed, but in my debugger
What do you see instead?
--> a new sln with "crashdump.dmp" in it, click it and nothing happens
What version of the product are you using?
--> latest
On what operating system?
--> win 7 64
Please provide any additional information below.
--> let me know what you need
Original issue reported on code.google.com by [email protected]
on 23 Jul 2010 at 8:44
What steps will reproduce the problem?
1. compile your app (possibly relevant: under parallels, using a mapped
".psf" network drive to access files on the mac HFS+ drive)
2. run
3. purposely crash the app
What is the expected output?
--> crash reporter comes up
What do you see instead?
--> crash does not come up, instead i get a dialog saying "crash sender
failed". Shouldn't the reporter come up before the sender even runs?
What version of the product are you using?
--> 1.2.2
On what operating system?
Win Vista 64 Enterprise, running under Parallels 5.0.9344 rev 558741 on
MacOS 10.6.3 build 10D573
Please provide any additional information below.
info.uPriorities[CR_SMAPI] = 3;
info.uPriorities[CR_SMTP] = 2;
info.uPriorities[CR_HTTP] = 1;
i tried turning off "managed code" for crash sender with:
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\editbin.exe"
/NXCOMPAT:NO "../build/kJamsX Pro Debug.app/Contents/Windows/CrashSender.exe"
but that did not help
Original issue reported on code.google.com by [email protected]
on 17 Apr 2010 at 9:54
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.