Dig Deep, It’s There Somewhere…

One of the problems with working in IT, especially the support side, is occasionally you’ll come across a real belter of a problem which, in simple terms, sticks two fingers up at you and challenges you to fix it. I’ve had two of those in the last few months, one of them in the last week. They are the sort of problems that you either walk away from, save the customer data, format and reinstall the OS or, grab it by the throat and investigate, peeling it away layer by layer, until the cause is revealed and a fix is in place. The former is expedient, quick and keeps the customer happy, (sort of), until it happens again, whereas the latter is a learning experience, allowing you to discover first causes and find solutions which can be used again in other, similar. cases.

For me, giving up is never usually an option, unless the demands of the customer require it. Some people say I’m tenacious, others, “bloody-minded” but either way I like a problem I can get my teeth into, and these two certainly managed to provide dental exercise.

Both machines came in for the same reason, requiring anti-viral and anti-malware scans as they were both heavily infected. Machine A could barely browse the ‘net along with running exceptionally slow. A series of anti-viral and anti-malware scans revealed and removed the infections and careful removal of a series of “optimising” applications meant that the machine was eventually running normally with one exception: It could no longer browse the ‘net. It took several days of digging, testing and scanning, (along with running the shop, admin work, other repairs etc), to find out that the Winsock layer had been removed by one of the anti-viral or malware scans. Replacing the Winsock layer reinstated the machine’s browsing ability and the customer was happy.

Machine B had a similar problem, it could browse the ‘net but not any secure sites that used SSL (those that begin with HTTPS rather than HTTP). After looking up the problem in various places on the ‘net I re-registered a series of DLL’s, reset IE (several times), cleared the SSL cache, tried to install Chrome (failing due to SSL problems), made sure the machine was up-to-date, used the Repair Disk to run SFC (System File Scan), tried Safe Mode, (both IE and OS), all to no avail. I eventually decided to dig down using several tools contained in the SysInternals Suite. This eventually revealed that IE was trying to call the certificate revocation provider, which in this case was ‘CertSentry.dll’, installed by Comodo and since removed totally, (probably by one of the anti-viral/malware scans). Unfortunately, with CertSentry.dll missing, certificate revocation could not be checked and so the SSL connection was closed prematurely.

With Machine B, I was seriously considering saving the customer data and reloading the OS but I remembered the solution to the Machine A problem and decided against it and so, eventually, found the solution. Now I know what caused it, future problems of this type will be easier to sort out.

It appears that I have rambled on a bit in this post. My apologies for that.


One comment

  1. alexforshaw · November 6, 2014

    I can identify with this. As a software developer I occasionally encounter seemingly intractable faults. But the feeling when you solve one is priceless!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s