Windows Explored

I don’t trust uninstallers. They always tend to leave something behind. Every now and then one of these orphaned components still ends up not playing well with some other application or the OS, resulting in crashing user-mode apps or the kernel. A good example of this was a previous post where I was experiencing a BSOD when running Process Monitor (read about it here) after installing a Microsoft application.

So, we have a workstation that is about to be sent off to be re-imaged because iLinc, a web conferencing application, is crashing when the user tries to join a session. I intervene because I hate to see these issue written off as unexplained. Who knows, the system gets re-imaged, the user installs some application again and the problem repeats itself (which it would have been the case here).

It happened that Dr. Watson, the Windows XP post-mortem default debugger, was capturing the user-mode crash so I jumped in without hesitation:

!analyze –v reveals no surprises; there are a few 3rd party modules, all from the crashing iLinc application. I would need to look at earlier threads for clues. This can be accomplished in a GUI friendly type of way by going to the WinDbg View menu and selecting the Processes and Threads and Call Stack options. I arrange them side by side and select each thread, looking for signs of an exception or fault and then looking for the presence of other 3rd party modules. I find a couple interesting components, none that I have seen before on any workstations within the company:

Looking up the modules, I can see they are definitely 3rd party and both are part of the same application:

After some research on Internet, I find who Lenel is, locate the application in Add or Remove Applications and uninstall it. Not entirely convinced this is the culprit, I launch the A\V conference app again to see if I will be able to join a test session. I am disappointed to see it crash again. Oh well, perhaps I was wrong.

There is a popular saying among advanced Windows troubleshooters: “When in doubt, run Process Monitor.” So I fired it up, set a filter to trace the only operations on the crashing app, waited for the app to crash, and examined the log file. Nothing really stood out, and using the Count Occurrences feature didn’t reveal any results that, at first glance, might indicate a problem. With no idea what I might be filtering for, I started to manually scan the log file from the bottom up. Maybe some operation would stand out. That could be quite daunting as I was dealing with tens of thousands of operations. Luckily, I persist just long enough to find this a few minutes later:

And its partner:

I saw both of these in the user.dmp earlier. Annoyingly, these components are not uninstalled by the application that originally installed them. I figured I could manually delete the folder they resided in but I am always a bit hesitant about manually removing application components that persist, especially here because the orphaned folder was pretty large and contained a few exe files, several Dlls and other unknown types. I didn’t know what they might hooked into so I took a more cautious approach.

Maybe the Software website had a KB for uninstalling. Yep, there are a few more manual steps:

Ack! Even after doing this, the application is still crashing in the same manner, with the same components showing up as the culprit. Autoruns to the rescue. Surely, we can disable these components from starting up, right? Yes:

From here, it was just a simple matter of unchecking (or deleting) all instances of what was left behind by the uninstaller. One reboot later, iLinc was no longer crashing and I was able to successfully join a test session:

(Handsome guy)