As the topic states I have had a couple of BSODs in the last 4 days and there has been zero file/driver name, etc. that is usually attributed to a BSOD.
Stop error is 0x0000007E (0xC0000005, this is variable, 0x8078631C, 0x80785F00), see low res screen capture image attached.
I have uploaded DavidR_dump_files.7z to the ftp avast incoming location, 14,301KB compressed size. It contains one minidump from 17/7/2011, one minidump from 21/7/2011 and the full memory.dmp file from 21/7/2011.
I have my suspicions that this may well be an Outpost Firewall Pro 7.5.1 related BSOD as I had recently installed that update and not directly related to avast 6.0.1203. Though I have no supporting evidence in the actual BSOD screen and I can’t analyse the dump files.
use the utility bluescreenview to examine the minidumps. It gives you a lot more info and usually points to the offending driver (in this case, most likely, aswsp.sys)
Whilst the bluescreenview if fine for minidumps as far as I’m aware it doesn’t handle the full kernel memory dumps and it is these that reveal the full information.
Edit:
Having said that I have just updated my copy of bluescreenview and there are 4 drivers listed (two OS drivers) and aswSnx.sys (avast! Virtualisation Driver, a.k.a. sandbox) and Sandbox.sys (Agnitum Ltd {Outpost}. Host Protection Component).
So it could well be a conflict between these two drivers, hopefully the memory.dmp file will reveal more information.
After updating Outpost Firewall Pro from 7.5 to 7.5.1, I got my first BSODs on start up. After Windows Startup Repair, System Restore, Outpost Firewall was no longer listed in Programs and Features but folders and files remained. It looked a bit of a mess, so I decided to do a full recovery and now I’m back with Windows Firewall.
As I said there was 4 days between the two instances of a BSOD, so that really isn’t an option; who knows how long it might be before the next instance. Not to mention removing one element of any conflict doesn’t find the true cause/culprit, essentially that doesn’t help anyone.
Only perseverance and the submission of BSOD dump files is likely to get to the real issue so that it might be resolved to the benefit of all users.
I have been using outpost firewall for even longer than the 7+ years of using avast and never once an issue like this and it is only on my win7 system and not this XP Pro SP3 one.
Thanks DavidR for memory dump. Yes, this was a bug in virtualization driver and it’s already fixed now. Your system can bluescreen only during driver loading (not later when you logon to Windows).
Well That doesn’t appear to be the case, the first BSOD happened on a boot before I ever got to a logon screen.
The last one, whilst it also happened on a boot, I don’t know if there was some sort of conflict coming out of standby as my win7 netbook computer flatly refused to come out of standby (not hibernation) and I ended up having to use the power button to restart.
This gave me the usual windows recovered from improper shutdown (etc.) and I opted for a normal restart and that was when it got the second BSOD.
You say this has been fixed, I take it you mean in an internal build, otherwise it wouldn’t have happened ?
If and internal build, then if there is a patch I would be happy to install it and see how it effects the problem.
Any information on this “bug in virtualization driver and it’s already fixed now,” as in where it is fixed, internal build (?) and when this is likely to be released.
I have had it happen again today when I tried to start my netbook, I let it collate the bsod data and restarted the netbook. Since you said it only happens during driver loading before on restart I told windows to boot normally (not go through a repair, which can’t fix this bug) and it went into another bsod.
So I have rebooted and an running through the supposed Startup Repair option knowing it can’t do anything. So I’m going to cancel (only to find I can’t cancel it) that and see if I can get in on the third attempt to reboot.
Do want some of these minidumps and memory.dmp uploaded again to the ftp location ?
Do you actually use avast sandbox with outpost ,as the only way to allow avasts sandbox to work correctly with outpost is to let it create a global TCP rule ,though you can restrict it to your home lan.
With the avast free version you don’t have the full sandbox, just the autosandbox feature, which would still require the loading of the avast driver.
I actually don’t have a lan setup, just to stand alone PCs that connect through a my router, the win7 one using wifi and my XP box connecting through Ethernet cable. I don’t have any problem on my XP system.
So I don’t see how a global rule would have any impact when the conflict is happening so early in the boot when the drivers are loaded, before Outpost is fully loaded. This was never a problem prior to avast 6.0.1203 and even then had never happened before the update of Outpost to 7.5.1.
The problematic code was there for quite a long long time - so it’s interesting that you’re the first one who got that BSOD…
Anyway, please apply ap2011-24-07-001 patch from [b]http://public.avast.com/~kurtin/patches[/b].
I didn’t have time to test it for avast 6.0.1203, but it was working for later versions.
Ahh…I thought it was just safe zone that wasn’t included in the free edition ,and you are correct that ,it wont/shouldn’t cause any bsods.Out of curiosity,does the loading of the sandbox driver prompt ,outpost to create a rule for “system” ,or has outpost created a global rule ( like it does for pro or AIS?)settings>network rules>system wide rules
As far as I know, Outpost must create a fw rule for SafeZone browser – I think Outpost isn’t able to show a FW diaog with new rule on SafeZone desktop (because of bug in Outpost fw). I haven’t tested SafeZone with FW apps, because I didn’t have a lot of time… but when I finish sandbox development for avast7 I’ll start with SafeZone improvements for avast7 incl. FW testing.
Yes outpost in auto learn or allow all ,does not adequately allow avast sandbox (i.e a sandboxed broswer) or safezone to run correctly ,although allowing global rule for tcp and https will allow it to work.I agree it is an outpost problem.
