Why would anyone want to do that ?
Sometimes one can restart explorer in this fashion rather then really reboot to cause options that would require a reboot otherwise to come into effect. Also, if somebody is trying to debug certain add-ons you would need to terminate explorer before compiling a new one, but I highly doubt this is the case here.
Incidentally, re the request to post a temporary explorer.exe
This is actually a common request. when an error dialog of this nature appears many people assume the file itself is corrupted.
However, in this case the cause of the issue was a trojan/virus, which probably did something such as insert appINIT_DLLs into the registry.
Note that when a "executable" crashes, it merely indicates what process crashed, not in what file the crash occured. a badly programmed DLL- (and bad programming practice is common and even encouraged in the underground community) will crash the process within which it runs if anything goes wrong. Generally an appINIT_DLL needs to take into account any number of threading models that a COM Server application such as Explorer may use; in this case it appears that one of the assumptions the program makes (probably due to the OS being different) causes the DLL to crash, and since DLL files are loaded In process with the executable and run in the same address space, the entire Program crashes.
In fact, one might also assume that the "details" described by the fault dialog would indicate the "real" culprit as the cause, but this is usually not the case. For example, if a DLL tries to use an invalid pointer, which usually takes the route of passing an invalid memory address to an Windows function, that DLL function will crash, because, being a low-level Function it requires the fastest speed and can't spare time to validate it's arguments. Most of these sorts of crashes are pinpointed to ntdll.dll, which contains the Windows Native API that higher-level functions such as those in the more famous kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, etc call into to perform their jobs.
(in fact, some functions in these "higher level" dlls are merely exported symbols that forward directly to a routine in ntdll, the reason being that the function was moved to ntdll for some reason, but they left the symbol in it's old location for compatibility purposes. Such Forwarding is done by LoadLibrary, and the jump address is relocated to the address of the new function. This way there is no performance impact of an extra function call, which would be the case if the "compatibility routine" instead called into the new routine in ntdll.dll.
