Good evening.
This is to report you a problem I’m encountering with Avast 4.7 Home on Win2000 Pro, and resulting in a blue screen or a reboot.
Debugging with WinDbg and Verifier was hard, but the problem is probably due to the driver aavmker4.sys (version 4.7.892.0).
Here is the information I could gather:
The PC has an Athlon 2600XP Barton processor, brand new 1Gb SDRAM and fast IDE disks.
The system is Win2000 + SP4, lovely skimmed: really goes like a rocket and absolutely stable excepted this problem: no problem even with video, fast scrolling, etc.
Also I could run MemTest for hours with no error.
The only offending job is the compilation of a Web site, based on a makefile alternating NT console file operations and tools like SED, M4… on a wide number of small text files (20Kb max).
Here is a typical rule from the makefile:
$(TargetDir)/%.html.php : $(SourceDir)/%.page.src $(ChunkList)
@echo .
@echo Processing $<
@echo . Catenating…
SplitFile $< -o:ThisFile.work -m:##### -silent
type Head-ThisFile.work | sed.exe -f SedMakeM4Header.txt > HeadM4-ThisFile.work
type Body-ThisFile.work | sed.exe -f SedPreM4Replace.txt > ThisFile.work
SplitFile ThisFile.work -o:ThisFile.work -m:##### -silent
type $(ChunkDir)\Header.m4.src > ThisFile.work
type HeadM4-ThisFile.work >> ThisFile.work
type $(ChunkDir)\DTD.html.src >> ThisFile.work
type $(ChunkDir)\GenericMeta.html.src >> ThisFile.work
type $(ChunkDir)\PageHeadTags.html.src >> ThisFile.work
type $(ChunkDir)\IEStyleHacks.html.src >> ThisFile.work
type $(ChunkDir)\GenericHeadEnd.html.src >> ThisFile.work
type $(ChunkDir)\GenericBodyTop.html.src >> ThisFile.work
type Head-ThisFile.work >> ThisFile.work
type $(ChunkDir)\GenericBodyManager.html.src >> ThisFile.work
type Body-ThisFile.work >> ThisFile.work
type $(ChunkDir)\GenericBodyEnd.html.src >> ThisFile.work
type $(ChunkDir)\GenericEnd.html.src >> ThisFile.work
@echo . Compiling…
copy ThisFile.work $(*F).html.php > nul
@echo ====== Compiling $(*F).page (rule 2) ====== >> M4ERROR.txt
m4 -P -Dztm4Mode=$(Mode) --error-output=M4ERROR.work $(BaseDir)/$(*F).html.php > $(BaseDir)\M4-ThisFile.work
type M4ERROR.work >> M4ERROR.txt
SplitFile M4-ThisFile.work -o:ThisFile.work -m:##### -silent
type Head-ThisFile.work | sed.exe -e /^^$$/d > Define-ThisFile.work
@echo . Moving…
@echo copy -y- “Body-ThisFile.work” “$(TargetDir)$(*D)$(*F).html.php” > Copier.work
type Copier.work | sed.exe -e s/\g -e s-y-_/y_g > CopyOne.bat
call CopyOne.bat
copy /y Define-ThisFile.work $(TargetDir)_heads\Define-$(*F).txt > nul
del /f /q $(BaseDir)$(*F).html.php
$(Wait)
So this creates a lot of small files through console commands, that must (in functional meaning) be serialized. This compilation completely works when there is no crash.
But it randomly crashes, and I could see that it may occur even between simple operations like the “type >>” sequence. So there are no unsafe EXEs or critical processes (network, video, etc.) at this time.
According to WinDbg, this is due to a memory corruption caused by a faulty driver, and it produces a STOP in ntoskrnl.exe. Types IRQL_NOT_LESS_OR_EQUAL and PFN_LIST_CORRUPT are alternated.
See attached WinDbg !analyze results.
I could check with Verifier that aavmker4.sys is the only driver a bit busy during such a compilation.
Also the following tips have a visible effect on the problem (I did many tries):
- adding a sleep 1 second after every rule (this is the role of the $(Wait) at the end),
- defining the compilation directory in Avast’s exclusion list (but it keeps watching CMD.exe and the Temp directory),
- setting Verifier to monitor the driver (so all becomes very slow),
=> all reduce the “crash probability”, what means that it may occur every 4th compilation, while in normal condition, not a single one can complete.
- deactivating Avast background protection before compiling is the most efficient improvement,
=> allowed me to complete 10 full-speed compilations without crashing (maybe I could have tried more).
My theory is that in such a situation, where Avast tries to perform a scan of every executable run and every file created, for minutes and on a “fast” machine like mine, the driver may be outrun by the processes, stack too many contexts and finally explode its work area…
Also (maybe related) I’ve already seen the string “C:\Programs\ALWIL~” inserted in some of the batch echoes.
But this is your part of the investigation.
You won’t probably have problems to reproduce the conditions, even without a complete makefile, just with a batch file processing this way in a loop the same little files.
I will follow the results in the forum, and use one of my workarounds to be able to compile in the meantime.
Thanks, good luck and best regards.
/**************************************************************\
- Patrick BRUNET
- F / 06130 Grasse
- E-mail: registered
**************************************************************/