Author Topic: BSOD #8e in aswmon2.sys  (Read 7981 times)

0 Members and 1 Guest are viewing this topic.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
BSOD #8e in aswmon2.sys
« on: August 08, 2009, 02:47:29 AM »
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.

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11765
    • AVAST Software
Re: BSOD #8e in aswmon2.sys
« Reply #1 on: August 08, 2009, 11:26:31 AM »
Without the dump, I'm not sure there's anything we can do.
Could you send the minidump at least? It shouldn't contain any private information.

What exactly are your settings of avast! blocker?
« Last Edit: August 08, 2009, 11:40:50 AM by igor »

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #2 on: August 08, 2009, 07:54:30 PM »
Without the dump, I'm not sure there's anything we can do.
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.

Quote
Could you send the minidump at least? It shouldn't contain any private information.
No can do.

Quote
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.

Offline Lisandro

  • Avast team
  • Certainly Bot
  • *
  • Posts: 67274
Re: BSOD #8e in aswmon2.sys
« Reply #3 on: August 08, 2009, 08:08:28 PM »
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...
The best things in life are free.

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11765
    • AVAST Software
Re: BSOD #8e in aswmon2.sys
« Reply #4 on: August 08, 2009, 08:36:23 PM »
Having the source, and possibly a way of reproducing the problem, your task is substantially easier.

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.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #5 on: August 08, 2009, 11:05:27 PM »
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.
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.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #6 on: August 08, 2009, 11:14:03 PM »
Having the source, and possibly a way of reproducing the problem, your task is substantially easier.

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.
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.

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11765
    • AVAST Software
Re: BSOD #8e in aswmon2.sys
« Reply #7 on: August 08, 2009, 11:57:50 PM »
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.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #8 on: August 09, 2009, 03:35:35 AM »
Thank you for looking at this. Is there any analog to the behavior blocker planned for 5.x, or is the entire concept kaput?

Offline pk

  • Avast team
  • Super Poster
  • *
  • Posts: 2085
Re: BSOD #8e in aswmon2.sys
« Reply #9 on: August 09, 2009, 01:19:44 PM »
Please wait for final 5.x version and then see for yourself.
Just as you, we don't share such information with people who are not disposed to help us.

Take care of the minidump and keep your massive ego afloat.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #10 on: August 09, 2009, 08:40:49 PM »
Please wait for final 5.x version and then see for yourself.
Just as you, we don't share such information with people who are not disposed to help us.

Take care of the minidump and keep your massive ego afloat.
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.

Offline pk

  • Avast team
  • Super Poster
  • *
  • Posts: 2085
Re: BSOD #8e in aswmon2.sys
« Reply #11 on: August 09, 2009, 08:53:34 PM »
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.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #12 on: August 10, 2009, 01:31:01 AM »
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...

I'm not sure that there is any safe way for a non-MS component to access the fields of an EPROCESS struct. The DDK docs say, "PsGetCurrentProcess returns a pointer to an opaque thread [sic] object", so using it would be risky, at best. For example, EPROCESS might be pageable. There's considerable discussion of how to get a process name in a driver at OSROnline. http://www.osronline.com/showThread.cfm?link=30302 ; http://www.osronline.com/showThread.cfm?link=66922 ; http://www.osronline.com/showthread.cfm?link=95086 , etc., but there appears to be no good way to do this in kernel mode.

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.

Quote
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.
« Last Edit: August 10, 2009, 01:35:16 AM by zerospam »

Offline Vlk

  • Avast CEO
  • Serious Graphoman
  • *
  • Posts: 11665
  • Please don't send me IM's. Email only. Thx.
    • ALWIL Software
Re: BSOD #8e in aswmon2.sys
« Reply #13 on: August 11, 2009, 11:08:50 AM »
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. :)

Thanks
Vlk
« Last Edit: August 11, 2009, 12:34:13 PM by Vlk »
If at first you don't succeed, then skydiving's not for you.

Offline zerospam

  • Jr. Member
  • **
  • Posts: 54
Re: BSOD #8e in aswmon2.sys
« Reply #14 on: August 11, 2009, 07:20:16 PM »
I analyzed the dump and I now understand what the problem is. We'll fix this in the next build (coming soon)....
Thank you. I'm glad that you were able to reproduce and fix the problem.