Tag Archives: blue screen

STOP: c0000135 – The program can’t start because consrv is missing. Try resintalling the program.

Posted on by
33

Getting this error?  Wouldn’t you know, it’s actually the product of a nasty little rootkit called ZeroAccess MAX++ of which you might be familiar.  The particular variant that causes this error actually uses the consrv.dll file to ensure it is able to load at boot on 64-bit systems.  As such, among other items, this rootkit drops a file called consrv.dll into the %SYSTEMROOT%\system32 folder.  It’s the reference to this file in the registry which wreaks said havoc once the file is removed by any means (antivirus, offline deletion, etc.).

To rectify the problem, you will need to gain access to the %SYSTEMROOT%\system32\config\SYSTEM registry hive remotely (whether by Recovery Console’s regedit and the Load Hive… command or by booting to another operating system and loading the hive in similar manner) and change an entry modified by the rootkit back to its default value.

The infected machine will have a modified string (REG_EXPAND_SZ) data of the Windows registry value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\SubSystems which looks like this:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=consrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16
This value is wrong, and it’s the reference to consrv which is generating your c0000135 stop error.  Instead, change it to:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

This will solve the problem and enable the machine to boot.  Please note that you should also modify the same value in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\… for completeness.

For a little more background/ancillary info, on the machine I was repairing which experienced this issue, the rootkit was accompanied by an additional MBR bootkit of the family Rootkit.boot.Pihar.a.  TDSSKiller actually took care of this one and restored the clean MBR.  In addition, plenty of other malware was along for the ride (all of it predictably hidden by the rootkit combo).  It was a nasty situation, but nothing I couldn’t handle. 😉
I hope you have found this case study useful.  Please let me know if it has helped you!

TDL4 removal leads to Windows 7 64-bit stop error on boot

Posted on by
2

I’m proud to say that it’s been literally two years since I’ve reformatted a PC due to malware, and I’ve disinfected many hundreds in that time period. But yesterday, I encountered a PC infected with TDL4 (which I’ve dealt with many times), however this one was a Windows 7 64-bit machine. Following removal of the rootkit offline via TDSSKiller in WinPE (set to scan Boot Sectors only), the PC began crashing on every boot, even when Safe Mode was attempted. The typical invasive offline procedures I use to rectify these issues — such as the disabling of nearly all third-party filesystem and NDIS filter drivers — did nothing to correct the issue. Restoring a previous System Restore point and even manually restoring the registry hives from the RegBack folder also accomplished nothing.

Finally, I decided to backup/restore the BCD. To do this, I used a Windows 7 recovery disc (in my case, ERD/MS DART) and opened a command prompt. From there, I (mostly) just followed the Microsoft guidelines for restoring a corrupted BCD:

c:
bcdedit /export C:\BCD_Backup
attrib -s -h c:\boot\bcd
ren c:\boot\bcd bcd.old
bootrec /fixmbr
C:\boot\bootsect.exe /nt60 all /force
bootrec /RebuildBcd
bootrec /FixBoot

(Note that C: must be replaced with the relevant Windows drive.)

This corrected the issue on this PC. I hope this helps someone in the future!

Post-disinfection Stop Error: c000021a

Posted on by
1

On multiple occasions over the past couple of years (since kernel-patching rootkits have become prevalent), I have encountered a particularly troubling STOP Error that most often technicians simply respond to by running a repair or clean install of the operating system. It looks something like this:

STOP: c000021a {Fatal System Error}

The windows Logon Process system process terminated unexpectedly with a status of 0x[various] (0x[various] 0x[various]). The system has been shut down.

Where [various] represents any number of hexadecimal error codes that may apply.

In this case, simply restoring the registry to a previous state as I’ve written about before does not correct the problem.

There are posts and pages to address this situation scattered across the internet, but nearly all of them offer different solutions, and most of them don’t seem to work. Microsoft has a page that relates the issue to Windows NT OS, blaming it on the PendingFileRenameOperations registry key which is often used by malware and antimalware to perform a rename operation on reboot. However, fixing this key as they suggest also does not solve the problem.

Most often, when it’s encountered post-disinfection, I find that the problem relates to an issue with a patched system file. I’m not certain, but it nearly always seems to be winlogon.exe.

Regardless, there is one and one only way to ensure the problem is corrected: find and replace the suspect file! There are multiple ways to accomplish this:

  1. Boot to a custom OS or slave the drive, check the system files (or run a virus scanner through them), and replace the faulty files with good copies (see below).
  2. Run a system file check from the Windows Recovery Console by typing sfc /scannow.
  3. Boot to an MS DART ERD Commander disc for Windows XP and run a system file repair from within the environment (this is my method of choice).

If you are forced to manually inspect and/or replace the files, I suggest checking for Company information and investigating any files which are missing the usual Microsoft Corporation info. If a suspect file is encountered, check its MD5 hash and Google it to see if it’s a known patched copy.

Once the culprit(s) has been identified, navigate to the system32\dllcache folder and copy the corresponding file there to its correct location. If it isn’t there or the copy is also bad, restore it from the Windows CD, or look for a folder called \i386. You can also run a search for the file throughout the entire Windows directory to find copies which have been downloaded for Service Packs and other Windows Updates. Just be sure to get the correct version.

In my most recent customer’s case, the files at fault were explorer.exe and winlogon.exe. Both had been patched by a rootkit and needed to be replaced. Once that was finished, the system booted up just fine.

If you’re looking for computer help in the Louisville area, look no further.  Call me today and get it done right!