That programs have bugs is a given in modern times. We all make mistakes, and even if we don’t, we use somebody else’s code, which may contain errors. When your program crashes on user’s computer, you should know about it, and that’s where Crash Reporting comes in. We all have seen it in Windows, MacOS X and even in KDE applications. But what if you want to add such capability to your own project?
As long as you’re only using mobile platforms like iOS, Android or Windows Phone, you have a rich choice of 3rd-party APIs which allows generation, collection and processing of crash reports. iOS has TestFlight. For a cross-platform applications, you may use HockeyApp SDK or CApptain. But on desktop, your choice is limited.
Actually, I was unable to find any free alternatives to Google’s Breakpad. The good news, however, is that Breakpad is a well-tested piece of code (it is used in Mozilla Firefox and some other major software products) and it’s certainly cross-platform. In fact, not only does it support desktop, but also mobile platforms!
However, its integration is far from straightforward.
1. Getting and compiling Breakpad on Windows
From what I can see, Breakpad does not offer any ready-made packages on its page. So, your only options is to check out its sources from Google’s Git via command provided here. After that, things begin to go slightly wrong. The documentation says “Once you build the solution inside src/client/windows, an output file of exception_handler.lib will be generated.” However, there is no Visual Studio solution in this directory. You have to generate it using Google’s alternative to CMake, gyp (Generate Your Project).
gyp is a Python script, so first be sure to download and install Python 2.7. A copy of gyp source tree is included in Breakpad Git, so you do not need to download it separately. To generate Visual Studio solution, run this string from command line (I’m assuming you have added %BreakpadFolder%\src\tools\gyp\ to your path):
2015 update:Well, Google decided to remove a section on building Breakpad for Windows completely from their documentation. Also, Gyp is no longer included in Breakpad repository (even though it would be much easier to to this with Git and its submoudles system). Still, basic steps remain the same: get Gyp, use Gyp to generate Visual Studio project, use generated project to build Breakpad.
First, you’ll need to check out Gyp in a directory somewhere. You’ll also need a copy of Python 2.7, which could be obtained from the official site. Then, assuming that you added Gyp root folder to Path or are using the full path to to batch file, you can use the following command line to generate a Visual Studio project:
gyp.bat –no-circular-check src\client\windows\breakpad_client.gyp -Dwin_release_RuntimeLibrary=2 -Dwin_debug_RuntimeLibrary=2
If you need to, you can also specify Visual Studio version, for which you want your project to be generated. I did it via environment variable “set GYP_MSVS_VERSION=2010”, but I guess you can just pass it throught command line with -DMSVS_VERSION=2010 (I haven’t tried it, though).
The first switch is necessary to make gyp work at all, since otherwise it will report an error. The second and the third switch is more interesting. In fact, it tells gyp to generate a project which will use “\MD” switch (Multi-Threaded DLL) instead of “\MT” (Multi-Threaded) when choosing CRT version. You may omit this, if you NEED to use static version of CRT, or specify 0 instead of 2.
This will generate \src\client\windows\breakpad_client.sln and various other files. The project generated by Gyp, however, would not compile by default. It seems like Breakpad’s maintainers are treating Windows as a second-class platform and do not bother to keep it working. The first thing you will need to do is to disable C/C++->General->Treat Warnings As Errors for all projects. Otherwise you will get errors in Windows SDK headers. Even after that, some projects still would not compile, because they lack necessary files or are mis-configured, but you should be able to get all you need for following integration steps: common.lib, crash_generation_client.lib, crash_report_sender.lib and exception_handler.lib.
Please note, that despite the fact that gyp is a cross-platform project generator, Breakpad ONLY uses it for generating Windows projects. On all other systems, you can use the usual configure && make process. This difference makes it harder to integrate Breakpad in a cross-platform product, but oh well…
2. Integrating Breakpad with your application
Google’s instructions about Windows Client Integration are perfectly OK in that they tell you what to do with your code. However, Breakpad authors advise to include the whole source tree for Breakpad in your project and build it along with everything else. It seems to me that whoever wrote this was bitten by a radioactive stupid. Breakpad is not a small library, with sprawling source tree, which even includes some binary files. You don’t need all this trash in your own repository.
However, Breakpad does not make it easy to separate end-user files (libraries and headers) from source files. You will have to do it by hand. Here’s a list of directories and files that you will need for basic integration (with sending of crash reports to server):
|--google_breakpad
|---processor
|---common
|--common
|---windows
|---client
|---windows
|---crash_generation
|---sender
|---handler
|---common
exception_handler.h
You will also need this libraries:
crash_report_sender.lib crash_generation_client.lib common.lib exception_handler.lib
You may want to clean those directories of .cc files and other trash.
Now, to make Breakpad work, in your application you will only need to include exception_handler.h, and, if you need to send crash reports to server, client/windows/sender/crash_report_sender.h.
Please note, that under other OSes, you will need a slightly different set of files and directories (oh, the pain).
Here, I will repeat a basic process for integrating Breakpad into your code.
First, include exception_handler.h and create an instance of google_breakpad::ExceptionHandler:
// Creates a new ExceptionHandler instance to handle writing minidumps.
// Before writing a minidump, the optional filter callback will be called.
// Its return value determines whether or not Breakpad should write a
// minidump. Minidump files will be written to dump_path, and the optional
// callback is called after writing the dump file, as described above.
// handler_types specifies the types of handlers that should be installed.
google_breakpad::ExceptionHandler *pHandler = new google_breakpad::ExceptionHandler(
L"dumps\\",
DmpFilter,
DmpCallback,
0,
google_breakpad::ExceptionHandler::HANDLER_ALL,
MiniDumpNormal,
L"",
0 );
Note, that the directory you have specified for storing dumps should already be created – Breakpad will not create it itself. Also, it should be writeable by your application, obsviously.
Callback functions (DmpFilter and DmpCallback) are needed if you want to do something when crash happens. For example, if you want to ask user if he WANTS to send you a crash report, you can do it in Filter callback, and then, if he answers yes, use CrashReportSender in Minidump callback.
For your convenience, here’s some information about constants used by ExceptionHandler:
enum HandlerType {
HANDLER_NONE = 0,
HANDLER_EXCEPTION = 1 << 0, // SetUnhandledExceptionFilter
HANDLER_INVALID_PARAMETER = 1 << 1, // _set_invalid_parameter_handler
HANDLER_PURECALL = 1 << 2, // _set_purecall_handler
HANDLER_ALL = HANDLER_EXCEPTION |
HANDLER_INVALID_PARAMETER |
HANDLER_PURECALL
};
For information about Microsoft’s minidump type (in example, MiniDumpNormal is used), see MSDN.
3. Sending crash information to server
You can just ask your users to send you minidumps generated by breakpad to your mail, or upload them manually, but Breakpad also includes facility for sending them to server directly. There is a class, called CrashReportSender in client/windows/sender/crash_report_sender.h, which is easy to use.
In your MinidumpHandler, write something like this:
// Instantiate CrashReportSender, specifying checkpoint file, where it stores information about number of dumps sent per day, to limit itself
google_breakpad::CrashReportSender sender( L"crash.checkpoint" );
// Set maximum numer of reports per day from one user, or -1 for unlimited reports
sender.set_max_reports_per_day( 5 );
// You can fill this map with additional params, for example, video adapter information or application's inner version, or something
std::map<std::wstring, std::wstring> params;
// Callback parameters do not give you an exact name of generated minidump file, but you can reconstruct it
std::wstring filename = dump_path;
filename += L"\\";
filename += minidump_id;
filename += L".dmp";
// Finally, send a report
google_breakpad::ReportResult r = sender.SendCrashReport( L"http://your.site.here", params, filename, 0 );
// Possibly notify user about success/failure
if ( r == google_breakpad::RESULT_SUCCEEDED )
MessageBox( 0, "Crash report was sent. Thank you!", "Crash report", MB_OK|MB_ICONINFORMATION );
else
MessageBox( 0, "Could not send crash report. Thank you for trying, though!", "Crash report", MB_OK|MB_ICONWARNING );
return false;
4. Receiving crash reports
Now that you have a client that sends crash reports, you may wonder where’s the server which will receive and store them. Unfortunately, Google does not provide such server, even a basic one. Unless you want to write one yourself (which could be easy or hard, depending on feature set), you have just two alternatives.
There is Mozilla’s Socorro server, which can handle millions of crashes per day, display all kinds of statistics about them, aggregate them in useful manner etc. Unfortunately, it’s a bitch to set up, because it has a list of dependencies long enough to scare a grown man, including non-negotiable PostgressSQL database. I haven’t even tried it.
The other server is mini-breakpad-server. It has very small number of features, but it’s far easier to set up, even though it requires Node.js. It only supports uploading and displaying of crash reports with resolved symbols, but it should be enough for the most small projects.
One thing it does NOT support is uploading of symbol files. Documentation specifies that you should upload them manually into pool/symbols/PRODUCT_NAME. This is a (partial) lie. Actually, your symbols should be stored in this way:
pool/symbols/ExeOrDllName.pdb/VERSION_ID/ExeOrDllName.sym
Note, that Breakpad does not use native symbol formats (pdb, dwarf or otherwise), but instead its own, which can be generated from native formats by running dump_syms or symupload tools, provided with Breakpad. VERSION_ID could be obtained from .sym file by looking for a long string of digits and letters in the first line of file.
After you have mini-breakpad-server set up correctly (don’t forget to change its directory’s ownership to a proper user!), you can now specify “http://your.site:1127/post” in call to SendCrashReport, and a minidump file will be uploaded.
This tools are bound to Visual Studio version. So, for example, if they are compiled with VS2013, they will NOT work with PDB files generated by VS2010. Versions, which are committed to Google’s Git are created in Visual Studio 2013. If you need to use them with some other version, you’ll have to recompile them yourself (which shouldn’t be hard), otherwise you’ll get some cryptic errors about msdia*.dll not being registered.
Returning to mini-breakpad-server, I found that you can’t install it using npm, as specified in documentation, because some dependencies are broken. However, you can just download it from GitHub and run npm install in its root directory. After that, run bin/mini-breakpad-server and watch it work (don’t forget to run it a a daemon if you want to collect crash reports at all times!).
I found the process of uploading symbols manually to be inconvenient, so I modified mini-breakpad-server to allow using Google’s symupload to upload symbols to correct paths from my Windows machine. Some time, I’ll try to get my changes merged into master branch, but currently you can download my modified version here: mini-breakpad-server-maxed.zip.
PLEASE NOTE: My version of server could now be obsolete; I’m not planning on maintaining it until I have the need to do it, so you might be better off by looking at one of the forks of original server, some of which are in active development
If you use this version, you can run
symupload YourProgram.exe http://your.server:1127/symbols
and symbols should be uploaded to a correct path.
5. Conclusion
I found all information necessary to get all this set up from examining source files and, in one case, running strace to find out where the hell does mini-breakpad-server looks for symbol files. I hope this post should make up somewhat for the lack of documentation for both Breakapd and mini-breakpad-server. If you have any further questions, feel free to post them here.
you explained about google breakpad, it is fine.
But, I need step by step procedure to compile and integrate google breakpad with my project.
Please provide that one.
Thanks in advance.
Naresh Gadupudi
The concrete instruction would depend on Breakpad’s features that you want to use, and your target platform (Windows/Linux/MacOS X/Android/iOS).
Here, I can only summarize what I wrote in the post above:
1) Install SVN and Python 2.7
2) Get Breakpad sources like described here: https://code.google.com/p/google-breakpad/source/checkout
3) Run src\tools\gyp\gyp.bat –no-circular-check src\client\windows\breakpad_client.gyp -Dwin_release_RuntimeLibrary=2 -Dwin_debug_RuntimeLibrary=2 from Breakpad’s root
4) Open Breakpad solution (src/client/windows/breakpad_client.sln)
5) Build all projects
6) Copy this files and folders to your project:
|–google_breakpad
|—processor
|—common
|–common
|—windows
|—client
|—windows
|—crash_generation
|—sender
|—handler
|—common
exception_handler.h
7) Copy this libraries to your project:
crash_report_sender.lib
crash_generation_client.lib
common.lib
exception_handler.lib
8) In your project’s main file, include exception_handler.h
9) Somewhere in start up of your project (possible at the beginning of WinMain function), create crash handler
google_breakpad::ExceptionHandler *pHandler = new google_breakpad::ExceptionHandler(
L”dumps\\”,
0,
0,
0,
google_breakpad::ExceptionHandler::HANDLER_ALL,
MiniDumpNormal,
L””,
0 );
Don’t forget to create “dumps” directory before creating ExceptionHandler.
This will make your project create minidump files in “dumps” directory. If you also want it to automatically send minidump files to your server, then instead of step 9 above, do this:
9a) Include client/windows/sender/crash_report_sender.h in your project
9b) Create function which will send minidumps, like this: params;
bool DmpCallback(const wchar_t* dump_path,
const wchar_t* minidump_id,
void* context,
EXCEPTION_POINTERS* exinfo,
MDRawAssertionInfo* assertion,
bool succeeded)
{
google_breakpad::CrashReportSender sender( L”crash.checkpoint” );
sender.set_max_reports_per_day( 5 );
std::map
std::wstring filename = dump_path;
filename += L”\\”;
filename += minidump_id;
filename += L”.dmp”;
google_breakpad::ReportResult r = sender.SendCrashReport( L”http://zxstudio.org:1127/post”, params, filename, 0 );
if ( r == google_breakpad::RESULT_SUCCEEDED )
MessageBox( 0, “Crash report was sent. Thank you!”, “Crash report”, MB_OK|MB_ICONINFORMATION );
else
MessageBox( 0, “Could not send crash report. Thank you for trying, though! Please report this crash at http:\\\\zxstudio.org”, “Crash report”, MB_OK|MB_ICONWARNING );
return false;
}
9c) In your WinMain, create ExceptionHandler like this:
google_breakpad::ExceptionHandler *pHandler = new google_breakpad::ExceptionHandler(
L”dumps\\”,
0,
DmpCallback,
0,
google_breakpad::ExceptionHandler::HANDLER_ALL,
MiniDumpNormal,
L””,
0 );
Hi Max,
Strange enough that the “mini-breakpad-server-maxed.zip” doesn’t have any source code.
I think it must be something wrong?
Uh… How did that even happen? I’m so sorry. I’ll upload correct version when I get home. Thank you for mentioning it!
OK, I updated the archive, now it should contain everything required to run a breakpad server.
It works like a charm!
By the way, I’m doing this for an application on mac.
Thanks Max.
Can Breakpad list MS dlls(like ntdll.dll) functions’ name in stack trace?
Thanks very much!
I haven’t tried it, but I see no possible problem. You’ll have to upload the correct PDB to Breakpad server for it to work, which you will first need to obtain from Microsoft Symbol Server (see bottom of the article for server’s address).
Hi. I’m having a prroblem i don’t manage to fix.
google_breakpad::ExceptionHandler *pHandler = new google_breakpad::ExceptionHandler(
L”C:\\Users\\Seb\\Desktop\\dump\\”,
0,
0,
0,
google_breakpad::ExceptionHandler::HANDLER_ALL,
MiniDumpNormal,
0,
0 );
This gives me a compilation error :
“error C2668: google_breakpad::ExceptionHandler::ExceptionHandler : ambiguous call to overloaded function
Have you ever had the same issue ? Any idea on how to fix it ?
Never mind. I am just silly.
I just wanted to know how do we generate breakpad symbols. I assume it can be built from the existing pdb’s.
You can use dump_syms or symupload tools, provided with Breakpad to generate breakpad symbols from existing pdb’s.
I have multiple projects in my visual studio solution.Could you tell me how to generate the same for all the pdb’s generated and feed the same to minidump processor. any commands mentioned regarding this in breakpad project. Could not find any intro for this online
First, pre-build dump_syms tool from Breakpad repository (src\tools\windows\dump_syms\). Place it somewhere inside your project, for example, to $(SolutionDir)/tools folder.
Add a custom post-build step to all projects. In it, call dump_syms with the name of output PDB file (%(ProgramDatabaseFile)) and redirect output to a file like that:
$(SolutionDir)/tools/dump_syms.exe %(ProgramDatabaseFile) > $(ProjectName)_$(ConfigurationName).sym
This should produce symbols file which could be later uploaded to breakpad server or used locally.
Thanks for the timely reply. Will try that and will let you how it goes.
“Google’s SVN via command provided here”
When I click on here it does not exist shows up can you please update the latest URL.
Thanks in advance…..
Thank you for notifying me. Google moved Breakpad’s site and moved sources to a Git repository. I’ve updated necessary links.
Hello Max,
I pretty much integrated breakpad into my project. But i am facing a problem in launching the crashreporter.
I have initialized crashreporter in my main application cpp file and have passed address for minidump callback to lauch the modified crashreporter to ask user to send report to particular server.
I have deliberately included crash in wxapp main source file, It works fine and lauches crashreporter. But if i include my crash code anywhere else in the program, It not calling crashreporter. After debbugging i found that its not calling the minidump callback at all. Its just exiting the application. Am i missing something. Please help
I’m not sure I can help you without seeing the whole code of your project, but here are a few suggestions.
First, you say that minidump callback is not called. Do you mean that both filter and dump callbacks ( DmpFilter and DmpCallback) are not called, or only dump callback?
Second, I think that if your program launches several threads, then it is possible that crash callback is only set for the current thread. You may not even launch threads by yourself, but maybe wxWidgets is doing it, or something else. I haven’t tried multi-threaded case myself, so I’m only guessing here.
Third, it is possible that some other library is overwriting callbacks with its own ones after it is initialized. I do not think this is the case, but it is possible, so check what else is happening after you set breakpad’s callbacks, but before entering the main app code.
You can also try to move crash location around until you nail the line where callback stops working.
Yes its a multithreaded application. Is there any special initialization in case including breakpad in multithreaded application or setting crashcallback for all threads. Both DmpFilter and DmpCallback are not called.
I don’t see anything about threads in documentation, and as I said before, but then again, Breakpad isn’t very well-documented. I haven’t encountered this situation myself, so I’m afraid I can’t help you much.
Thanks for your suggestions. While i am looking for solutions I just found that my application is launching the crashreporter for invalid parameter crashers( printf(NULL)) at all places in my project.
I was trying with nullptr and access denied intentional crashes before.May be breakpad does not handle all types of exceptions
Breakpad code (https://chromium.googlesource.com/breakpad/breakpad/+/master/src/client/windows/handler/exception_handler.cc) suggests that it should handle invalid parameter (see void ExceptionHandler::HandleInvalidParameter). You may want to try to place a breakpoint inside this code to see if it gets called when such error happens.
Actually i meant other way. Exception handler is called when there is invalid paramter but not when null pointer exception occurs.
Breakpad should handle those also via SetUnhandledExceptionFilter as long as you pass HANDLER_EXCEPTION or HANDLER_ALL to ExceptionHandler constructor. A thread on SO (http://stackoverflow.com/questions/11350801/why-does-google-breakpad-not-handle-all-crashes-how-can-i-debug-these-cases) suggests that it can sometimes fail, and also folks at Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=844196) ran into problems with Breakpad on Win64 builds (it doesn’t seem like Breakpad implemented vectored expection handlers since then).
Just cloned the git repo, there’s not gyp.bat file in %BreakpadFolder%\src\tools\gyp\ and also anywhere in the sources tree. Stucked in generating the solution file. Can you please help ? Thanks
Google moved Gyp out of Breakpad repository, so now you’ll have to check it out yourself. I’ve updated the post with the new instructions, but I was unable to verify them because my Visual Studio installation is currently borken. You can try them for youself, however.
I’ve updated the instructions with the new information about making generated project compile (by default, it’s broken).
How to integrate google-breakpad in the release version without the pdb file？
You’ll have to enable pdb generation for your release build. Of course, there is no need to ship pdb along with exe – just use it for symbol generation.
I tried using your modified mini-breakpad-server and ran into “Bad things happened: undefined” when I try to view a dump file.
I’m using the latest break-pad client
It is possible that the version I modified is now too old. You can try some of the new forks on GitHub here: https://github.com/electron/mini-breakpad-server/network
First of all, thank you for a detailed and up-to-date guide on building breakpad using VisualStudio. I thought I would mention how I solved some of the issues with the generated solution.
When generating the solution using gyp you should use -Dwin_debug_RuntimeLibrary=3 or 1 for static linkage. For example:
`gyp.bat –no-circular-check src\client\windows\breakpad_client.gyp -Dwin_release_RuntimeLibrary=2 -Dwin_debug_RuntimeLibrary=3`
Otherwise you end up linking to the release library when building debug and you get an unresolved symbol for _CrtSetReportMode.
Also, the unit tests fail to build unless you put googletest in the correct location. I didn’t use the breakpad readme recommend “depot tools” which may already do this, but I found if you pull down https://github.com/google/googletest.git and use mklink to setup the paths you can get it all to compile. For example if breakpad and googletest are synced to the same directory you can use the following commands to setup the shortcuts:
`
mkdir src\testing
mklink /d src\testing\gtest ..\..\..\googletest\googletest
mklink /d src\testing\src ..\..\..\googletest\googlemock\src
mklink /d src\testing\include ..\..\..\googletest\googlemock\include
`
Thanks again for the guide, I’ll be continuing on with setting up a mini-breakpad-server next.
Thank you for your comment. I haven’t used Breakpad myself for quite a while now, but it seems like it still somewhat of a mess on Windows, and gyp certainly hasn’t gotten any better too. A pity, since alternatives are pretty much non-existent.
Thank you Mike! This helped me ! Thanks to MaxEd too. Without your blog post, I don’t know what I would have done.
Worked like a charm. I am able to create the dmp files from my QT application now. However, the dmp files is not very helpful with the stalk walker. I am a little confused on how to read the dmp files. I have managed to create the symbols file from the project pdb files. (VS2015). Not sure how to make the dmp file useful enough to get the stack tree.
Sorry, was on a vacation, could not answer. To get anything useful out of DMP files, you should apply symbols generated from PDB to them. If you’re using a server to upload symbols, it should be done by server, but if you want to do it by hand, I see Chromium has some instructions (https://www.chromium.org/developers/decoding-crash-dumps), or there is a ready-made tool by someone on GitHub (https://github.com/walac/breakpad-symbolicate)
I did all you say but I’ve no idea why i get linker error 1120 🙁
__thiscall google_breakpad::ExceptionHandler::ExceptionHandler(class std::basic_string<wchar_t,struct std::char_traits,…..
However Treat wchar_t as Built-in Type in all breakpad sub-project is off
Could you post the full compilation log to Pastebin or some other site like that and link it here? I can’t say anything from this incomplete string along.
Sorry for bad format : http://pastebin.com/ARJGzhPY
Actually this happens when i attempt to create instance of ExceptionHandler and on both winAPI and Qt project will occur
Hm, I can see nothing wrong with your code at the first glance. Are you sure you are linking Breakpad’s library to your project?
Yeah.
I finally managed this by building all necessary windows dependencies as part of my project.
I haven’t touched Breakpad for a long time, so I’m not sure why just linking a library didn’t work, but I’m glad you found a workaround.
I think I have mentioned this earlier, but got everything sorted in generating dump files. Got the symbol files ready. Just reading them does not give me any clue or line numbers. Says the crash reason but that is it. Almost every line says the symbol files are not loaded.
Is there a way to use Visual Studio for this? Because loading the symbol files is not helping in VS too. Kind of stuck with all these dump files.
http://pastebin.com/Ks9pDrHR
No, you can’t use Visual Studio to add missing symbols to Breakpad files. Visual Studio only works with its own crash dump format, which Breakpad can’t use since it’s not cross-platform. If you’re stuck completely, you can try finding function names by hand, by creating the “map” file for your application (there is a setting somewhere in VS for doing it), and then looking up the function with address nearest to one in the call stack, e.g. 0x42d584 in case of “AgileDesigner.exe + 0x42d584”. But this is a tedious and error-prone process, so let’s see if we still can get Breakpad to do it.
As you can see from the log you posted, the problem probably lies with this string:
“MinidumpModule could not determine debug_file for C:\Program Files\Grid-Tools\AgileDesigner\AgileDesigner.exe”
According to MinidumpModule source and a thread on Google Groups (https://groups.google.com/forum/#!topic/google-breakpad-dev/PD1cQgzwpT4), this probably happens because your exe file does not include any debug info record, i.e. it was created without the “/Zi” flag (which does not affect optimization, but only PDB file generation, and therefore should be safe to turn on even in production builds distributed to users).
Hİ Max,
Thank you for your post. I have a problem with mini-breakpad-server. When I run “npm install .” it gives error and I can not run the server. Dou you have any idea about error?
Thanks in advance
npm WARN deprecated wrench@1.5.9: wrench.js is deprecated! You should check out fs-extra (https://github.com/jprichardson/node-fs-extra) for any operations you were using wrench for. Thanks for all the usage over the years.
npm WARN deprecated node-uuid@1.4.7: use uuid module instead
npm WARN deprecated jade@0.35.0: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated minimatch@0.2.12: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated graceful-fs@1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use ‘npm ls graceful-fs’ to find it in the tree.
npm WARN deprecated jade@0.28.2: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated transformers@2.1.0: Deprecated, use jstransformer
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
> minidump@0.9.0 install C:\breakpad_server\node_modules\minidump
> node-gyp rebuild
C:\breakpad_server\node_modules\minidump>if not defined npm_config_node_gyp (node “C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js” rebuild ) else (node “” rebuild )
Building the projects in this solution one at a time. To enable parallel build, please add the “/m” switch.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets(44,5): error MSB8020: The builds
tools for v140 (Platform Toolset = ‘v140’) cannot be found. To build using the v140 build tools, either click the Proje
ct menu or right-click the solution, and then select “Update VC++ Projects…”. Install v140 to build using the v140 bu
ild tools. [C:\breakpad_server\node_modules\minidump\build\minidump.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `msbuild` failed with exit code: 1
gyp ERR! stack at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:276:23)
gyp ERR! stack at emitTwo (events.js:106:13)
gyp ERR! stack at ChildProcess.emit (events.js:191:7)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command “C:\\Program Files\\nodejs\\node.exe” “C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js” “rebuild”
gyp ERR! cwd C:\breakpad_server\node_modules\minidump
gyp ERR! node -v v7.2.1
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
npm WARN caliper@0.0.1 No license field.
npm ERR! Windows_NT 10.0.14393
npm ERR! argv “C:\\Program Files\\nodejs\\node.exe” “C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js” “install” “.”
npm ERR! node v7.2.1
npm ERR! npm v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! minidump@0.9.0 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the minidump@0.9.0 install script ‘node-gyp rebuild’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the minidump package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs minidump
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR! npm owner ls minidump
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! C:\breakpad_server\npm-debug.log
I solve this problem but the is an other problem since you wrote this block breakpad source code changed and it do not allow you to send “filename” directly you have to send “std::map” object so when I do this I always get “Could not send crash report. Thank you for trying, though” message here is my code.
// Instantiate CrashReportSender, specifying checkpoint file, where it stores information about number of dumps sent per day, to limit itself
google_breakpad::CrashReportSender sender(L”crash.checkpoint”);
// Set maximum numer of reports per day from one user, or -1 for unlimited reports
sender.set_max_reports_per_day(5);
// You can fill this map with additional params, for example, video adapter information or application’s inner version, or something
std::map params;
// Callback parameters do not give you an exact name of generated minidump file, but you can reconstruct it
std::wstring fileName = dump_path;
fileName += minidump_id;
fileName += L”.dmp”;
std::map files;
files.insert(std::pair(L”testFile”, fileName));
// Finally, send a report
google_breakpad::ReportResult r = sender.SendCrashReport(L”http://192.168.2.6:1127/post”, params, files, 0);
// Possibly notify user about success/failure
if (r == google_breakpad::RESULT_SUCCEEDED)
MessageBox(0, L”Crash report was sent. Thank you!”, L”Crash report”, MB_OK | MB_ICONINFORMATION);
else
MessageBox(0, L”Could not send crash report. Thank you for trying, though!”, L”Crash report”, MB_OK | MB_ICONWARNING);
From a look at the new code for SendCrashReport, I can’t see anything wrong with your approach. However, there might be a problem on server side. Previously, the name of file Breakpad sends, was hardcoded to “upload_file_minidump”. Now, you can specify several names. In theory, you must rewrite the server to accept several files. However, for your present purposes (i.e. sending one file), I believe it might be enough to change “testFile” to “upload_file_minidump” in your code.
Thank you for reply.
I solved problem before like your metion but I forgot add comment here.
I work at Backtrace I/O, https://backtrace.io. We are building a drop in replacement for Socorro which is easy to deploy, aims to give you its full feature set, and is actively support. We’re a commercial software company but we just released Breakpad and Crashpad support under free public beta. If anyone out there is interested in trying it out, feel free to sign up at backtrace.io/create or reach out to me at amathew@backtrace.io
Looks interesting. Do you plan to keep any part of your product free after the beta? On one hand, such an extensive service does not make much sense for small/hobbyist projects, but on the other, having crashdump analysis can be useful to them, and there is no middle ground between bare-bones solutions like mini-breakdad-server and such services as yours. Maybe limit the number of crash reports per month for free users or something like that? Of course, an open-sourced self-hosted solution would be even better (and your company can still make money from clients who do not wish to set up their own server or wan support).
MaxEd — We are definitely exploring some of those options. I think limiting the # of crash reports / storage used makes a lot of sense and is a good middle ground between other options. Once we have a good idea on pricing, including the free tier, we’ll work directly with any of the folks signed up for the public beta. https://backtrace.io/create <– would be awesome to get your take.
That great to hear. Unfortunately, I just don’t have the time or a project that would benefit from your service right now. I bookmarked your site, and I’ll be sure to check Backtrace out if I ever need crash-reporting again. Maybe next month, after the current project at work is complete.
Hi Max,
could you please provide me other link for http://zxstudio.org/projects/mini-breakpad-server/mini-breakpad-server-maxed.zip. Looks this is broken.
Thanks and best regards
Thanks for your help MaxEd.