Condusiv Technologies Blog

Condusiv Technologies Blog

Blogging @Condusiv

The Condusiv blog shares insight into the issues surrounding system and application performance—and how I/O optimization software is breaking new ground in solving those issues.

Program not found - skipping AUTOCHECK - revisited

by Michael 30. December 2009 11:58

This is a reposting of a prior (and popular) blog entry that unfortunately was "chopped" when we migrated to our new platform. Here it is in full:  

Preface: this article refers to making direct edits to the Windows Registry. If you are not experienced with this subject, ask your company's IT Administrator or a computer-expert friend/neighbor for help.

Our Tech Support group has seen a few reports of this error (Program not found - skipping AUTOCHECK) from customers when running Diskeeper's bootime defrag. The error starts early in the boot process while the Session Manager process (smss.exe) is busy getting the system up and running. Smss.exe is critical to loading the paging file, initializing the registry and loading kernel components. But, before it does any of that it looks to a registry key called BootExecute. At that location it launches any applications listed. Session Manager then looks to the Windows system32 folder for particular executables it has been instructed to launch. By default there is only one program listed here - autochk.exe, the boot-time version of chkdsk, which will run if there are any file system inconsistency flags detected (i.e. volume dirty bit is set).

Read on for the solution...

Software vendors who need exclusive access to a volume (such as a defragmenter) will name proprietary executables at this registry location (and place the programs in the Windows system32 folder). Using this system is how Diskeeper is able to safely defragment files that could not be defragmented when the system is up and running.

However, malware creators have also used this BootExecute location to load their spyware/virus crap.

If you uninstall a legitimate program that has written into this BootExecute registry you may see this message. The uninstall will typically delete the executable from the system32 program, but not edit the registry. In most cases, the registry change is only a temporary one. For example: if you set Diskeeper to run a Bootime defrag "on next reboot" but uninstall it before the reboot, you can create the same issue. Once the Diskeeper Bootime defrag completes, it removes this string from the registry. Other applications are likely to behave similarly. It is also possible that a program, during install, writes data into this key, but then does not remove it on uninstall.

Another possibility is if you have run an anti-malware program that has removed the referenced executable from the system32 folder, but not changed the BootExecute registry to remove the "pointer" to that file. In that case you will also see this message.

When the program named is from a removed third-party vendor, the message is harmless. You should only be concerned if the default autochk program itself does not run.

If you do get this error and want to clean it up, here's what you need to do:

Look in the registry at:

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager" and remove the string [the name referenced in the message on system startup] from the BootExecute value.

Under normal circumstances only the following would be present:

autocheck autochk *

This is what it might look like with added values:

autocheck autochk * autocheck stera

You can change the value back to the default (as shown in the first example above), but understand that it may possibly impact a legitimate program listed here.

Stera.exe is part of an adware program that pretends to be an anti-adware program!

As always, you need to be very careful editing the registry. If you see anything else listed here other than the executable named in the error message, look at named file's properties in the system32 folder or do a web search on it. A legitimate vendor can advise you on what to do to avoid potential conflict.

For Diskeeper it would look like:
autocheck autochk * autocheck AUTONTFS E: PAGE=KEEP DIRS=NONE MFT=MIN

(where E: represents the drive letter on which to run the bootime).

You can also reset it back to the default (autocheck autochk *) without issue. That is the safest bet with Diskeeper. You'll simply need to go back into Diskeeper and reset the Bootime job.

Diskeeper customers are always welcome to contact our support team for assistance.

Tags:

Comments (3) -

12/16/2009 11:09:13 PM #

FYI:

Here is the original, archived posting with helpful reader comments and feedback:
web.archive.org/.../

Michael United States

2/24/2010 7:20:47 PM #

Hi,
This is what i've done.
Make a copy from the file AUTONTFS.EXE (from the diskeeper directory)and place this file in the C:\WINDOWS\SYSTEM32 directory.
Now it works perfectly.

Leo Netherlands

3/11/2010 3:31:28 AM #

BIG BIG THANK YOU!!!   For a long time that Autocheck would slow the warm or cold boot by a few seconds. With no other problems followed the "ain't broke, don't fix" policy, partly due to no obvious place to begin. While 'walking' through the site stumbled on the blog and found the root cause and the fix all in one place.

Frank Thomas United States

Comments are closed

RecentComments

Comment RSS

Month List

Calendar

<<  November 2018  >>
MoTuWeThFrSaSu
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

View posts in large calendar