This BSOD occurs frequently, usually (always?) when I’m linking an .EXE file. I have Avast’s blocker enabled, so that’s when I’d expect to see a blocker message. Instead, after having linked my EXE perhaps 100 times, I get this BSOD instead. It seems pretty readily reproducible, though I haven’t intentionally tried to reproduce it.
The BSOD arguments are c0000005 (accvio), aeca87d2 (faulting address), aeda97dc (trap frame), 0. aswmon2.sys is based at aeca4000, and has datestamp 498a51ea.
I am use XP 32 bit version, with SP3.
While I know that it would be helpful, I cannot send you a dump.
C’mon. I’m a developer, and have not infrequently had to debug BSODs from other peoples’ drivers (including MS’s) based only upon the information from the BSOD screen and from disassembling and reverse-engineering the relevant code. And sometimes the problems weren’t even reproducible. Having the source, and possibly a way of reproducing the problem, your task is substantially easier.
Could you send the minidump at least? It shouldn't contain any private information.
No can do.
What exactly are your settings of avast! blocker?
I'm using the default extension set, with blocking enabled for open for write, renaming, deleting, and formatting. And my default is to block an operation if Avast can't ask. Oh yeah, I'm using Avast 4.8.1335 with the (rather old) VPS 090624-0.
The problem could be there. Set no blocking at all. This is an old feature that won’t be present in avast 5 and it worked a long time ago for old malware, not more a necessary tool nowadays.
By the way, it will make things easier if you can just upload the minidump…
It’s kinda ridiculous to scan the dumps for the matching one and then disassemble it and match it against the source code. But yes, it’s possible. However, crucial information is missing anyway - such as the values of the registers, content of the memory pointed to by the registers, etc.
I like this feature. It can be a bother, but it’s also informative, and does give a user a last chance to avoid something nasty. Please consider keeping it, perhaps with the default being disabled.
You know the build and VPS numbers, so you can retrieve the matching source and VPS from your source-control system. A very limited amount of disassembly (e.g. via the /FAcs compiler switch) on the relevant module (found via the link map) will show you what variable’s dereferencing caused the crash. From there, code inspection – of which, in my experience, you can never have enough – probably will reveal what caused the crash. Admittedly, this kind of diagnosis is more difficult than that you can do using a dump, but it’s far from impossible.
I quickly checked the code at the crash location, and didn’t see anything suspicous (though I’m not the author of the code, so I don’t know the details).
I’ll put it this way: this feature is rather useless in the current form, almost nobody uses it. We are currently rather busy with avast! 5 - where, as Tech said, this feature will be dropped altogether.
So, while it would certainly be nice to have this fixed, either for avast! 4.x which will be supported for some time, or for the case this code is reused in the future, there are too many things to do right now with higher priority - so I don’t expect to spend time on this problem if it can’t be fixed very quickly.
So, my suggestion for you is to disable the Behavior Blocker.
I don’t mean to offend. I work under constraints that prohibit me from providing any material (like dumps) that might contain private data. I’m sure you would want your doctor, your lawyer, your pastor, and others in similar positions of trust to guard your data in the same way. As for my comments on driver debugging without the benefit of dumps, I did not mean it to be egotistical. I meant it to show that it is possible to debug driver problems with very little information.
BTW, I am a longtime customer and have recommended Avast to others. Your message makes me uneasy about continuing to use the product.
With your BSOD information, I was able to find the given .sys file and localize the line in the source file. However, without registry information ESI/EDI, I can’t say what is wrong. Suspicious code block copies short process name into our buffer (4 times: movs dword [edi], dword [esi]). Process structure (PEPROCESS) should be ok and our allocated buffer as well…
Sometimes 4 values from BSOD screen is enough, sometimes we ask for kernel dump, because minidump contains very few information and we don’t see structure contents. It depends. Minidump should contain very few private information, just list of driver names + registers and memory content of those regs… Sorry I got a bit uptight.
Presumably you’re doing this to display the process’s executable’s name in the blocker message. You could get the process’s PID in aswmon2, and pass it back to the user-mode program that displays the blocker message, and have that call OpenProcess and GetModuleFileNameEx . [1] This might be open to spoofing, but some on OSROnline assert that this is also true of the value in EPROCESS. http://www.osronline.com/showThread.cfm?link=30302 .
'Course, this might all be moot.
Sorry I got a bit uptight.
Apology accepted.
[1] You probably need aswmon2 to increment the process’s reference count to prevent the process from getting killed and its PID from getting reused by another process. I suppose that ObReferenceObjectByHandle will do what you need.
I analyzed the dump and I now understand what the problem is. We’ll fix this in the next build (coming soon).
BTW, zerospam, thanks for the suggestions - but as I assumed, none of them were really relevant (which is not necessarily because you don’t know what you’re saying, just because an analysis of such issues can be very tricky and you obviously can’t see the whole context as you haven’t written the code)… we’ve been in the NT driver business for over a decade now and I’d say we’re reasonably competent and know what we can (and can’t) do in the kernel.
It’s easier than that… we just have access to the Microsoft WER (Windows Error Reporting) data, so any time a crash occurs, and !analyze -v blames one of our drives, we can get the dump (minidump from XP, and possibly even a complete dump in Vista/W7).
So it was just a matter of looking up the particular bucket ID (driver name + offset).
