Yet another “case of the unexplained” type issue has found it's way to my door step,
unlike in previous instances, this time the client was able to point me
in a general direction providing a description of the issue.
He claimed that it was impossible to access the drive's secondary partition labelled "D:\".
For the sake of disclosure it was an XP machine that couldn't be upgraded
due to compatibility issues with the particular type of machinery it was operating.
I set sail.
Sure enough, whenever I try to access the secondary partition ( D:\ ) explorer.exe
(the shell) crashes, no matter if the access was directly to the root of "D:" or to a folder
present inside the directory using 'Run' for example.
As long as explorer.exe was used in conjunction with "D:\" it would fail and restart.
(for example the 'dir' command, no involving the shell, didn't have a negative effect).
Naturally you would think that malware might be involved in some manner,
but the system was actively protected by well renowned engines
(which would remain anonymous) so that was of low probability
(later scans, after the fact, confirmed that the system was clean).
I (obviously) turned to the Sysinternals Tools,
my first choice was Process Explorer (procexp.exe) to get a better view of the overall system activity at a glance and possibly getting a clue of some sort.
Nothing popped-up or looked even remotely suspicious, okay leaving procexp open and monitoring I turned to trusty Process Monitor (procmon.exe).
With procmon up and tracing I crashed explorer.exe on demand
hoping to catch the error or the offending process in action.
After a couple of induced faults and spending a decent amount of time analysing
procmon's traces individually and side by side comparing between them
(a very effective and popular technique) following the “normal procedure”
of plausible cause filtering methods have left me with nothing.
I stopped, closed procexp / procmon and thought.
That is when it hit me, I have nothing! That's it!
No error message, no log, no fault indicator of any kind!
Which is why I turned to Procdump. A tool which I have grown to cherish very quickly.
I open a command prompt window (Win+R > cmd.exe).
Changed directory (cd\) to where I had placed procdump for convenience,
in the root of the primary partition “C:\procdump.exe” .
I set procdump monitoring for explorer.exe exceptions, capturing a full memory dump
(using the -ma switch), when it crashes (using the -t switch),
and place the dump file in a folder I have manually created in advance “C:\dumps\”.
The syntax was as follows:
C:\>procdump.exe -ma -t explorer.exe C:\dumps\
Okay great procdump is all set and on guard.
I press “Win+E” launching explorer which defaults to “My Computer”,
I double click "D:\", halt and success!
Procdump spits out an error code, it was 0xc0000005 (Access Violation)
perfect, that in combination with the full memory dump
I'm positive I'm on the right track.
Carrying the post-mortem dump file onto my main debugging PC,
that still has Debugging Tools for Windows 7 (which still supports XP)
for cases such as these, with the good 'ol Windows Debugger or Windbg.
Double clicking the .dmp file (I am able to simply double click .dmp files
because I have set the correct file associations)
which can be set like so:
1. Elevated cmd.
2. cd into the path where Windbg.exe is located in your system,
for example mine is “C:\debuggers”.
3. Run this command (no quotes) “windbg -IA”.
Windbg will then prompt you that the file associations were successfully
carried out then you may accept the prompt and exit the debugger.
Other wise, you have to open Windbg and click on file and choosing
“Open Crash Dump...”
or using the keyboard shortcut “Ctrl+D” .
// End interlude.
Opening explorer's dump file generated by Procdump
revealed a very unusual cause.
In-line with the initial Procdump revelation
of an access violation the dump file, naturally, had more information to share.
After calling upon the debugger's internal heuristics engine by using “!analyze -v”
the results pointed to no other then a codec,
the particular codec was “FFDShow” (MPEG-4 Video Decoder).
It showed that it was a “null_ptr_ref”, null pointer reference.
In short what happens is that the codec, for some reason,
tried to access an address in memory that it didn't own or didn't exist.
To maintain a fair playing field I didn't uninstall the codec
right off the bat in spite of the deeming evidence.
I achieved that by using another Sysinternals Tool called Autoruns,
which (as the name implies) allows you disable the automatic execution
of many components on your system with codecs being among them.
Launched Autoruns.
Disabled the entry for “ffdshow” and restarted to take affect.
Feeling confident, I navigated to "D:\", not a hiccup.
SOLVED.
// I ended up unistalling the codec entirely as it wasn't necessary
on that particular machine's usage model.
unlike in previous instances, this time the client was able to point me
in a general direction providing a description of the issue.
He claimed that it was impossible to access the drive's secondary partition labelled "D:\".
For the sake of disclosure it was an XP machine that couldn't be upgraded
due to compatibility issues with the particular type of machinery it was operating.
I set sail.
Sure enough, whenever I try to access the secondary partition ( D:\ ) explorer.exe
(the shell) crashes, no matter if the access was directly to the root of "D:" or to a folder
present inside the directory using 'Run' for example.
As long as explorer.exe was used in conjunction with "D:\" it would fail and restart.
(for example the 'dir' command, no involving the shell, didn't have a negative effect).
Naturally you would think that malware might be involved in some manner,
but the system was actively protected by well renowned engines
(which would remain anonymous) so that was of low probability
(later scans, after the fact, confirmed that the system was clean).
I (obviously) turned to the Sysinternals Tools,
my first choice was Process Explorer (procexp.exe) to get a better view of the overall system activity at a glance and possibly getting a clue of some sort.
Nothing popped-up or looked even remotely suspicious, okay leaving procexp open and monitoring I turned to trusty Process Monitor (procmon.exe).
With procmon up and tracing I crashed explorer.exe on demand
hoping to catch the error or the offending process in action.
After a couple of induced faults and spending a decent amount of time analysing
procmon's traces individually and side by side comparing between them
(a very effective and popular technique) following the “normal procedure”
of plausible cause filtering methods have left me with nothing.
I stopped, closed procexp / procmon and thought.
That is when it hit me, I have nothing! That's it!
No error message, no log, no fault indicator of any kind!
Which is why I turned to Procdump. A tool which I have grown to cherish very quickly.
I open a command prompt window (Win+R > cmd.exe).
Changed directory (cd\) to where I had placed procdump for convenience,
in the root of the primary partition “C:\procdump.exe” .
I set procdump monitoring for explorer.exe exceptions, capturing a full memory dump
(using the -ma switch), when it crashes (using the -t switch),
and place the dump file in a folder I have manually created in advance “C:\dumps\”.
The syntax was as follows:
C:\>procdump.exe -ma -t explorer.exe C:\dumps\
Okay great procdump is all set and on guard.
I press “Win+E” launching explorer which defaults to “My Computer”,
I double click "D:\", halt and success!
Procdump spits out an error code, it was 0xc0000005 (Access Violation)
perfect, that in combination with the full memory dump
I'm positive I'm on the right track.
Carrying the post-mortem dump file onto my main debugging PC,
that still has Debugging Tools for Windows 7 (which still supports XP)
for cases such as these, with the good 'ol Windows Debugger or Windbg.
Double clicking the .dmp file (I am able to simply double click .dmp files
because I have set the correct file associations)
which can be set like so:
1. Elevated cmd.
2. cd into the path where Windbg.exe is located in your system,
for example mine is “C:\debuggers”.
3. Run this command (no quotes) “windbg -IA”.
Windbg will then prompt you that the file associations were successfully
carried out then you may accept the prompt and exit the debugger.
Other wise, you have to open Windbg and click on file and choosing
“Open Crash Dump...”
or using the keyboard shortcut “Ctrl+D” .
// End interlude.
Opening explorer's dump file generated by Procdump
revealed a very unusual cause.
In-line with the initial Procdump revelation
of an access violation the dump file, naturally, had more information to share.
After calling upon the debugger's internal heuristics engine by using “!analyze -v”
the results pointed to no other then a codec,
the particular codec was “FFDShow” (MPEG-4 Video Decoder).
It showed that it was a “null_ptr_ref”, null pointer reference.
In short what happens is that the codec, for some reason,
tried to access an address in memory that it didn't own or didn't exist.
To maintain a fair playing field I didn't uninstall the codec
right off the bat in spite of the deeming evidence.
I achieved that by using another Sysinternals Tool called Autoruns,
which (as the name implies) allows you disable the automatic execution
of many components on your system with codecs being among them.
Launched Autoruns.
Disabled the entry for “ffdshow” and restarted to take affect.
*Windows XP logon sound takes me back*
Feeling confident, I navigated to "D:\", not a hiccup.
SOLVED.
// I ended up unistalling the codec entirely as it wasn't necessary
on that particular machine's usage model.
