Working with windows shell is a tricky affair. Its open architecture allows all and sundry to write a shell extension, say add a command to the context (right click) menu for text files. Writing shell extensions is relatively simple for today's programming standards and as a result there are tons of them out there, and many are buggy. xplorer˛ integrates with windows shell architecture so most things that work in windows explorer are also in xplorer˛, including bug-ridden extension DLLs. The majority of crashes you may experience working with xplorer˛ are invariably caused by such poorly programmed DLLs — but xplorer˛ takes the blame!
Today I want to set the record straight and explain in simple terms what happens and how can you tell that a crash is in xplorer˛ or in some external module. That should clear xplorer˛ of most charges, yer honour <g>
First a crash [sic] course on address ranges. Each program takes space both on the hard disk and in computer RAM memory when running. For simplicity let's say that the operating system allocates 2GB of room for each running executable. The lower part, from byte #0 to byte #16,000,000 (the lower 16MB or 0x01000000 in hexadecimal) is taken up by the program itself (xplorer˛). Addresses above 0x01000000 are occupied by DLLs. If a program is big (many bytes) its address space will be full of machine code, otherwise it will be mostly empty space. No program is 2GB anyway — although microsoft are getting there with vista.
DLLs or Dynamic Link Libraries are partial programs (like subroutines) that offer services to processes like xplorer˛. The code that draws push buttons in dialogs is an example of something furnished by a system DLL (USER32.DLL). I don't need to write code that draws buttons, I just link to USER32.DLL and have it for free — how convenient! When windows loads xplorer˛, it also loads all the necessary DLLs and places them in the high memory area above address 0x01000000.
All shell extensions are DLLs, so they end up in xplorer˛ address space, and their subroutines are getting called from time to time. If the code is badly written, causing this or the other fault (eg. access violation), windows stops xplorer˛ and reports a crash. It's like you invite someone in your house and he gets drunk and burns it down.
Most of the DLLs that crash xplorer˛ are written in a language called Delphi. Not that it is inherently lame, but I suspect somebody wrote a sample shell extension that was buggy, and then many people built their own using this sample as a starting point so they copy/pasted the same troublesome code. If the crash is on exit and reports Runtime Error 216 it is definitely a Delphi error.
With all this information we can now decipher information in crash dialogs. The crash address, where program instruction pointer was, gives away where was the crash, whereabouts in the program address space. If the location is above 0x01000000 then it is a DLL fault, if it is below then it is a xplorer˛ fault.
Can we find which DLL caused the crash? With a little detective work we can. First we need to install process explorer. This can show loads of interesting information, including how a program's address space is laid out. We just need to find which DLL occupies the faulting address, where the program execution was interrupted. If say LAME_NSE.DLL is mapped in the region 0x01000000—0x01500000 and the crash is at 0x01200000 then it is code in LAME_NSE.DLL to blame.
I wrote a namespace extension DLL that is crashing on purpose to demonstrate the procedure. You can see it in action in today's debugging demo
Once you find your culprit, you may want to uninstall it through control panel or use a tool like ShellExView to disable it. Or if you are a true stoic you can just ignore the crash and get on with your life <g>. Crashes on exit are not a real problem for your system or your files — and definitely not xplorer˛'s fault!
|© 2002—2008 Nikos Bozinis, all rights reserved|