Windows: Create minidumps for threads terminated by exceptions #813

wants to merge 3 commits into


None yet
6 participants

CrystalP commented Mar 26, 2012

Hopefully with this and build symbol files it will be easier to figure out what crashed XBMC or a thread on a user's computer.

The PR will create the dumps in the same directory as the debug logs, with file names like:
XBMC majorminortag gitrev datetime.dmp

In case the exception happens before XBMC directories settings were initialized (unlikely), I'm not sure what's the best location for the dump. I thought of a few possibilities:

  • in the same directory as the exe. Maybe a problem for restricted users? It's what the PR implements at the moment
  • in the root of a user's Windows profile
  • in Windows temp directory. Same as the task manager would do.

What do you think, keeping in mind there are regular and portable installs?


jmarshallnz commented Mar 26, 2012

Looks fine to me. For exceptions at startup I'd dump it in temp I think as at least you know it's writeable.


CrystalP commented Mar 26, 2012

I also favor temp.
But I'll have to redo this PR as I found there already was minidump creation code in XBMC_PC.cpp and it seems silly to duplicate it.


wsoltys commented Mar 26, 2012

The current mini dump code is only executed if XBMC got a uncaught exception and exits. You might wanna change that to support the rest of the caught exceptions. The dumps shows not much without the pdbs which you already requested from TheUni. I think for 80% of the current exceptions the xbmc.pdb is enough :)


Montellese commented Mar 26, 2012

Nice work. This should make tracking down those win32 crashes quite a bit easier. I'd favor the windows temp directory as well as it should always be writeable.

Is there already a way for us to get the PDB of billy's builds?


CrystalP commented Apr 24, 2012

Here it is reworked, dumping on exception in any thread. I need to test a bit more, but that's pretty much it.
Handling on main thread is a bit inconsistent, to be fixed later.
The pdb files are supposed to be automatically archived now. We'll see when nightlies are turned on.


Montellese commented Apr 24, 2012

The PDB of the test build TheUni did yesterday was automatically uploaded alongside the EXE, see


theuni commented Apr 24, 2012

that one was done manually. from now on, they'll be alongside nightly builds. last night's was the first to run successfully:


CrystalP commented Apr 25, 2012

OK, works fine most of the time. The dmp file is not always valid though and dumping with more than minimal information sometimes hangs - maybe that has to do with the recommendation to do the dump from another process.

It's already better than nothing though, so I think it should go in the May merge window.


wsoltys commented Apr 25, 2012

pull it in.


dersphere commented Apr 26, 2012

Should I include these .dmp files to be uploaded by the "XBMC Log Uploader"-Add-on? Crashlogs for OSX/IOS/Linux are already included.


CrystalP commented Apr 27, 2012

That'd be a good thing, however how would you know which file(s) to upload?
The .dmp files are going to pile up from one XBMC session to the next. Even the same session could generate multiple .dmp
Maybe I should add a cleanup to avoid accumulating too many dumps, or at the start of xbmc delete all previous .dmp files.
That could be added later, I don't consider it blocking for merge.


dersphere commented Apr 27, 2012

At the moment the add-on looks for matching files (would be .dmp in that case) and asks the user if he want the most recent (sorted by mtime) to be uploaded.


CrystalP commented Apr 30, 2012

That would work most often.

CrystalP was assigned Jun 25, 2012


wsoltys commented Aug 13, 2012

rebased #1285

wsoltys closed this Aug 13, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment