Just another WordPress.com site
Monthly Archives: February 2012
I composed this topic as I reminder for me and probably others who always forget all those registry paths.. See references at the bottom of the page.
So if you are using Windows Vista (or above) and have an application (let’s call it crash_me.exe) that crashes often and you want to generate crash dump in an unintended manner so that whenever it crashes – a dump is generated without user involvement – you’ll need to perform these two steps:
Step 1: Specify that a dump should be generated for your application by adding the following to the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\crash_me.exe]
- DumpFolder REG_EXPAND_SZ – directory to hold the dump files
- DumpType REG_DWORD – Value: 2 (type of dump – full dump)
Step 2: Ensure that Windows Error Reporting UI is not shown by setting the following value (otherwise, crash dump generation won’t be performed until user selects anything in the “has stopped working” pop-up dialog):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
- DontShowUI REG_DWORD – Value: 1
UPDATE: If you’re on Windows 7 then Fault Tolerant Heap might create obstacles for your troubleshooting process. Next steps were added specifically to deal with FTH (taken from MSDN article on Fault Tolerant Heap):
Step 3: Disable FTH (requires reboot): set HKLM\Software\Microsoft\FTH\Enabled to 0
Step 4: Reset FTH mitigation configuration: Rundll32.exe fthsvc.dll,FthSysprepSpecialize
- MSDN articles: Collecting User-Mode Dumps, Fault Tolerant Heap
- Codehead’s article How To Disable “X has stopped working” Popup In Windows Vista
I use it so often, so that if it didn’t exist I would write one today :) For convenience, I usually place it into ~/bin/www (followed by
chmod +x ~/bin/www). On Windows I just ensure that ‘py’ file extension is mapped onto Python 3.2 executable.
For example the following console command:
grep -s -r -e "Error:" -e "Warning:" *.log | www
would open a browser (or add a new tab into an already opened browser window) with the output of the grep.
Here is a screen of
dmesg | www
command with BIOS pattern marked as yellow:
Here is a bit of history that might be of interest to developers.
Few years ago, as I was studying I/O area of the C++ standard library, I wrote a small tool that transformed its STDIN input into a temporary HTML file. Though by that time I had only the educational goal, I found this tool to be surprisingly useful in my working environment – as I often have to analyze logs (typically after some grep operations on them) and due to my dual-monitor setup I find it very convenient to issue some command on one screen and see the results on the other.
The only major change before I stopped working on it was adding a ShellExecute call in the end – so that the newly generated HTML file was opened automatically in the default browser (
which must be chrome which is chrome in my case). I just put it into a local SCM and kept it for few years without changes.
Next battle was for Unicode support. Or, to put it correctly, total lack of such support in the language. I tried to avoid WinAPIs for that and to be able to handle windows-1251, UTF-16 BE/LE and UTF-8 encodings – I had to spent few nights reading quite a number of materials on iwfstream and codecvt (not the best reading, imo), which is neither simple to use nor beautiful conceptually. And still, removing BOM-checks in C++ classic iwfstream-based code was a great pain. And, OMG!, after I ensured it works on Windows – it just didn’t work on Linux… though it was a personal free-time development, instead of bringing satisfaction and joy – it was just nasty time waste. Finally, though I’ve got to a stable point with support of cp1251 and UTF8, I just didn’t feel I want to proceed any further.
And here comes Python!
Just for sport interest, I tried to reach the same functionality by using Python 3.2 and total time spent until I got it working on two platforms I’m interested in was around 2 hours of coding and debugging.
Benefits brought by Python:
- single-file executable with no dependencies. Even though Python version had platform-agnostic parts too, they were typically one-liners and there was no reason to move them into separate modules. In C++ I had to implement platform-agnostic (and even linker-agnostic for Linux) resource embedding, cross-platform code to open browser and it naturally resulted in multiple headers/source files.
- Unicode. Python 3.x rulez here: standard distribution of the language has plenty of encodings supported out of the box, BOMs are removed automagically granted you’ve specified the correct encoding. It was pity to conclude that pure C++ with its standard library totally suck at this part.
- Performance – for a tiny tool like this I won’t even bother with runtime performance. Productivity is what matters here and Python is an obvious winner here. I admit it wasn’t clever for me to write such a program in C++ in the first place, but as I said it was an educational project and … I like to code in C++ anyway, at least when it’s not a unicode related code.