Friday, 8 August 2014

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 mein 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 upgradeddue 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 folderpresent 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 demandhoping to catch the error or the offending process in action.After a couple of induced faults and spending a decent amount of time analysingprocmon'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 dumpI'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 filesbecause 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 successfullycarried 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 Procdumprevealed a very unusual cause.In-line with the initial Procdump revelationof 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 codecright 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 executionof 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 necessaryon that particular machine's usage model.

About Process ID

Process ID, is a blog I use to share and recordmy personal experience of abnormal behaviourand extreme cases which bring Windows to its kneesand their resolutions.

I will attempt to walk you through my thought processand the chain of events, step by step,Including the tools I used and their respective commandswhich ultimately led me to a resolution.

This blog is aimed at providing both educationaland recreational content combinedto hopefully help those who are facing similar issuesfind a resolution and for those who enjoy the ever popular (which just happens to be themain inspiration for this blog)Mark Russinovich's "The Case of the Unexplained".