Blue screen with avast home

Avast Free Antivirus / Premium Security
1

hi, I have been using avast for over a year now, and everything has been fine up untill the last update or so, now when i use embedded links inside sites ie/java or flash this can sometimes trigger a blue screen from aws2.sys or something along those lines i cant remember exactly as i cant do a printscreen of blue scree, also if the computer is inactive for a while this bluescreen can occur randomly i think maybe it has something to do with the update software, i work with software and i cannot seem to work the problem out , its definatly your side, i have tested without avast for a few hours with no crashes at all, and my machine is fine and stable without infection or any bad hardware, this is a read eror i.e oxoo, im wondering if anyone has encountered the same problem or can shed any light on this.

edit: my friend is also experiancing the same problem

my setup : core 2 duo 6700 nvidia 8800 4 gig ddr , running windows xp pro

regards

phil

2

Please send me the contents of the \windows\minidump folder (by email) - ideally in a ZIP archive. To send me the email, just click the envelope icon below my picture.

Thanks
Vlk

3

i do not have a minidump folder in windows , i dont have a ‘minidump’ folder on my system at all

the only thing i can relate an error to is:

The server {22D6F312-B0F6-11D0-94AB-0080C74C7E95} did not register with DCOM within the required timeout.

4

Please, check
My Computer / Properties / Advanced / Startup and Recovery / Settings
What is the setting in the “Write debugging information” group?

5

%SystemRoot%\Minidump (small memory dump)

but the folder hasnt been created i guess its because it bluescreens rather than shuts down or gives an error

6

Bluescreen is exactly the moment when the minidump is created… strange.
If you search your disk for *.dmp files - do you get any hits?

7

my bad i wasnt waiting for the memory dump, i will email now

8

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
    **************************************************************/
9

Hi Patrick, and thanks for your extensive post.

However, honestly, I’d be surprised if this was an avast issue. Most often, bugchecks like this are hardware related. Alternatively, I’d check other non-MS drivers installed in the system as well.

The thing is, bugchecks happening inside the MM (memory manager) are usually caused by buggy drivers that incorrectly manipulate MDLs (or, of course, by hardware faults). But due to the nature of avast drivers, I’d reallty doubt if they were involved. If the crashes were happening e.g. down in an I/O path, I wouldn’t have any problem to assume it’s avast’s fault, but since this is not the case…

The reason you’re seeing aavmker4.sys is being “active” is quite simple - that’s where the bulk of avast scanning takes place. That is, there’s a big “running surface” here…

What you could try is disable scanning inside the driver (i.e. force the scanning to take place in user mode). To do this, open avast settings, go to the Troubleshooting page and check the “Disabled kernel-mode scanning” box.

Cheers
Vlk