Your client sent a MEMORY.DMP. Now what?
A server blue-screens overnight. By morning you have a multi-gigabyte MEMORY.DMP, zipped by whoever grabbed it, and a client asking whether it will happen again.
The usual options: open WinDbg and hope !analyze -v names a driver, send the dump to the vendor and wait, or reboot and move on. DumpTriage gives you a fourth.
Three steps
- Upload it as it is. A zip that holds one dump is unpacked on our side, so you don't have to extract it on a jump box first. Windows minidumps, kernel and full memory dumps, Linux core dumps and macOS crash reports all go through the same upload.
- Read the report. It names the driver or module that failed, shows the stack, explains the likely cause in plain language and lists next steps: update, roll back, or take it to the vendor.
- Hand it on. When the cause is a third-party driver, the report gives the vendor's support team the stack and the module, so the ticket doesn't start from zero.
When the automation isn't sure
Cases the automated passes can't settle go to an engineer, who works with the dump itself. We would rather do that than send back a confident wrong answer. How DumpTriage works explains when that happens.
One rule while we're in the pilot: our terms ask for synthetic or sample data only, so try it on a dump from your own test machine or lab first, not a client's. When you get to client dumps, is it safe to send a customer's crash dump? covers what to check. No AI model sees the raw dump, and dumps are stored and debugged in the EU.
Five places for MSP design partners
Three months free, an engineer's review included, and a 20-minute call each month to tell us what the reports got right and wrong.
See the terms