userenv.log filling up with autoexec.bat errors!

[mikesw]

I found that I'm filling up c:\windows\debug\userenv.log with the following error. It can

get to 25 megs in 24 hours.

USERENV(788.7e0) 07:10:42:953 ProcessAutoexec: Cannot process autoexec.bat.

For windows xp pro sp2 with patches, I don't have an autoexec.bat file

I've read that the number '788' when converted from hexidecimal to decimal is the process id

of the program causing the problem.

In my case it is the Savservice.exe which is associated with the Sophos anti virus program.

Is this common for Sophos anti vir and if not, how do i get Sophos to stop checking for

an autoexec.bat file?

[Tripredacus]

It is possible that your antivirus searches for batch files that may be viruses?

[mikesw]

It is possible that your antivirus searches for batch files that may be viruses?

Don't know about this.

However, if a create a dummy autoexec.bat in the root drive. The messages stop recording to the

log file; however, Sophos is still accessing the drive and running the bat file every few seconds.

The bat file just does an echo command. What a waste of computer time....

[Andromeda43]

It is possible that your antivirus searches for batch files that may be viruses?

Don't know about this.

However, if a create a dummy autoexec.bat in the root drive. The messages stop recording to the

log file; however, Sophos is still accessing the drive and running the bat file every few seconds.

The bat file just does an echo command. What a waste of computer time....

I'm running on a fairly recent install of Windows XP-SP3 and I do have an autoexec.bat and config.sys file

present in the root directory of C:

Those would only be usefull to a DOS bootup, or to running DOS programs.

Both are zero files (totally empty of entries)

I don't have Sophos on my PC, but I do use AVG 8.0 Pro.

I checked my own "Userenv.log" file and indeed I have entries concerning the Autoexec.bat file. ???

However, that file on my PC is only 138k in size.

I'm going to zero out that file and see what entries are added as the day progresses.

Later!

B)

PS:

There were hundreds of lines in that "Userenv.log" file. It appeared that all the entries concerning the Autoexec.bat file were at the beginning of the file. More lately there were NO such entries.

I've zeroed out that file and I'll watch it to see what goes in there from now on.

To simplify this, I've put a shortcut to that file on my desktop.

If it appeared that THAT file was causing me any problems or growing unnaturally, I'd add it to my XPCleanup.bat program that runs from my Startup folder so it would just be deleted on every boot.

Edited December 12, 2008 by Andromeda43

[Andromeda43]

It's amazing what you can find out, if you just put "Google" to the work for you.

On a M$ site, I read all about that log file and found this entry:

The Userenv log has a maximum size of 1 megabyte (MB). At system startup, if the log file exceeds 1 MB, the contents is copied into a Userenv.bak file and a new Userenv log is created. If the system remains running and is not restarted, the log file exceeds 1 MB.

That would indicate to me that you're not shutting your PC down at the end of the day.

That's highly recommended, even by M$.

XP was never designed or meant to be run continuously.

Many changes to the registry are made during a normal days work on an XP PC.

All those registry changes are held in the copy of the Registry that runs in system RAM.

They are copied to the master registry on the HD ONLY when the system is shut down,

even if it's just a brief re-boot.

If your system crashes during the day, maybe due to a brief power failure, all those updates to the registry are lost forever.

For systems that absolutely MUST be left on overnight, like to receive faxes, I always suggest putting a reboot command in the task scheduler.

XP relies heavily on a reboot to do much of its internal maintenance.

Just a thought!

Happy Holidays!

B)

Edited December 12, 2008 by Andromeda43

[mikesw]

Well,

I uninstalled sophos and its firewall, cleanup the leftovers and rebooted.

Now the autoexec.bat is still logged, but the process id it is associated with moves

around from one process to another. The files are OS related, ie. svchost.exe,

lsass.exe and one or two others. When I reinstall Sophos, it gets primiarly reassigned

to the savservice.exe process again. No adware,rootkits, or viruses are found with

sophos, superantispyware and Msofts month kb file for checking for rootkits etc.

Other co-workers PC's who have the same antivir software don't seem to have

this error being recorded in their userenv.log file.

Yes, I've read the MSoft article too, and although rebooting will cause the log file

to be less than 25megs, it's the idea that the autoexec.bat being recorded in it is

the issue since its every 1-2 minutes and filled with these entries.

I've done the following the registry to stop it short of turning off recording userenv.log altogether

based on the MSoft registry entries. Here's what other people have done to try and stop it.

) Setting the following registry configuration:

Hive: HKCU

Path: Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Key: ParseAutoexec

Value: 0 = autoexec.bat is not parsed

1 = autoexec.bat is parsed

Hence, I've set it to zero and will reboot to see if this clears the problem for autoexec.bat

[mikesw]

setting the parseautoexec in the hive to zero didn't stop it. I thus created a fake autoexec.bat

with this in it.

echo “@echo off”>>c:\autoexec.bat

However, Savservice.exe will keep trying to run autoexec.bat forever now that it is present.

It does stop the recording in the userenv.log though. I could also modify the registery

per the Msoft site for userenv.log and shut the logging off entirely, but I might need it

for other stuff in the future. So, I use the autoexec.bat technique for now.

I've replaced the echo off with just an echo "executing autoexec" which appends to another log file in the same directory

where the userenv.log is at to see if it actually executes the batch file. So far it doesn't, so the process id which checks

for autoexec.bat being present only checks for the file to exist, but doesn't execute it.

Edited December 13, 2008 by mikesw

[CharlotteTheHarlot]

...

XP was never designed or meant to be run continuously.

Many changes to the registry are made during a normal days work on an XP PC.

All those registry changes are held in the copy of the Registry that runs in system RAM.

They are copied to the master registry on the HD ONLY when the system is shut down,

even if it's just a brief re-boot.

If your system crashes during the day, maybe due to a brief power failure, all those updates to the registry are lost forever

....

Possibly back on Win3x, but definitely not now.

Dirty registry data is written out (aka flushed to disk) after a very short time interval, usually in mere seconds. This is the so-called lazy flushing. The System hive has an even tighter spec. It is very difficult to beat the timer. In order to lose data that is dirty in the registry but not yet saved to disk, you would practically have to have your hand on the power cable and yank it out immediately after pressing a key that made a registry change with the other hand!

The reason this is possible is because the entire registry (50 MB easy on WinXP) is not written out all at once when flushed, it doesn't need to be since only tiny amounts of dirty data is flagged. I believe it has been this way since NT and all the Win9x's. WinXP is certifiably bombproof in this area, as is Vista. Even on Win9x I don't think three seconds goes by without the little write to disk after I import a script or make handmade changes. There is a quick little freeze that occurs and might be missed unless you happened to be dragging a scroll bar down a very tall window or something. It is almost imperceptible.

When you are looking in language references at functions that use a Registry API flush there is usually a mention that it is unnecessary and potentially hazardous (infinite loops!) to the end-user's time and sanity. But many registry utilities of course need to use it anyway, as do many other programs. Consequently, there is almost no such thing as dirty registry data.

I'm not saying it is impossible to lengthen or disable the lazy flush, no doubt it is some obscure registry setting. It is definitely something not to be adjusted. Of course this has nothing to do with, say, a power loss with dirty disk data held in easily tweaked caches we all like to mess with. NTFS cured this for the NT family, but Win9x gets big blue Scandisks (99% cured by running System Internals Sync often).