Ignoring ASSERT w/ Chk Build + WinDBG

Is there a way to ignore certain assertions that end up in a DbgPrompt and
WinDbg requesting input?

I'm using XPSP2 and a checked hal, kernel and filter manager. I want the
assertions from the filter manager and some kernel assertions but I also get
ones for doing things that I don't care about. For instance, copying files
from a cmd prompt on the debug target to setup my debugging session causes a
boat load of assertions in MmIsNonPagedSystemAddressValid like the
following...

*** Assertion failed: MmIsNonPagedSystemAddressValid
(MemoryDescriptorList->StartVa)
*** Source File: d:\xpsprtm\base\ntos\mm\iosup.c, line 2939
Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread
(boipt)?

It would be so nice if I could ignore these automatically. I think I'm
probably missing something really simple but for whatever reason I haven't
been able to discover what it is. Any help would be greatly appreciated.

Thanks,
Jeremy Boschen

Don
Mon Jan 02 16:45:39 CST 2006

Well you might check the stack, and see if something you wrote is calling
MmBuildMdlForNonPagedPool with an invalid address. That is what this assert
is about, I've never seen not be valid.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Jeremy Boschen" <jboschen@ptd.net> wrote in message
news:OvkVfb%23DGHA.516@TK2MSFTNGP15.phx.gbl...
> Is there a way to ignore certain assertions that end up in a DbgPrompt and
> WinDbg requesting input?
>
> I'm using XPSP2 and a checked hal, kernel and filter manager. I want the
> assertions from the filter manager and some kernel assertions but I also
> get ones for doing things that I don't care about. For instance, copying
> files from a cmd prompt on the debug target to setup my debugging session
> causes a boat load of assertions in MmIsNonPagedSystemAddressValid like
> the following...
>
> *** Assertion failed: MmIsNonPagedSystemAddressValid
> (MemoryDescriptorList->StartVa)
> *** Source File: d:\xpsprtm\base\ntos\mm\iosup.c, line 2939
> Break repeatedly, break Once, Ignore, terminate Process, or terminate
> Thread (boipt)?
>
> It would be so nice if I could ignore these automatically. I think I'm
> probably missing something really simple but for whatever reason I haven't
> been able to discover what it is. Any help would be greatly appreciated.
>
> Thanks,
> Jeremy Boschen
>

Jeremy
Tue Jan 03 09:23:48 CST 2006

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:OH$eD5%23DGHA.2088@TK2MSFTNGP09.phx.gbl...
> Well you might check the stack, and see if something you wrote is calling
> MmBuildMdlForNonPagedPool with an invalid address. That is what this
assert
> is about, I've never seen not be valid.

It's not caused by something I wrote. It occurs before and after I have
loaded my minifilter. I was hoping there was a way to temporarily mask an
assertion because this particular one occurs 20+ times when I copy files or
open Windows Explorer which makes it a pain to get to the point where I can
start testing my filter.

Thanks,
Jeremy Boschen

Don
Tue Jan 03 09:28:14 CST 2006

Only thing I can think of is see who the culprit is, then see if you can
live without the driver that is issuing the call.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Jeremy Boschen" <jboschen[at]mutexed[dot]com> wrote in message
news:e2M$ymHEGHA.2036@TK2MSFTNGP14.phx.gbl...
> "Don Burn" <burn@stopspam.acm.org> wrote in message
> news:OH$eD5%23DGHA.2088@TK2MSFTNGP09.phx.gbl...
>> Well you might check the stack, and see if something you wrote is calling
>> MmBuildMdlForNonPagedPool with an invalid address. That is what this
> assert
>> is about, I've never seen not be valid.
>
> It's not caused by something I wrote. It occurs before and after I have
> loaded my minifilter. I was hoping there was a way to temporarily mask an
> assertion because this particular one occurs 20+ times when I copy files
> or
> open Windows Explorer which makes it a pain to get to the point where I
> can
> start testing my filter.
>
> Thanks,
> Jeremy Boschen
>
>
>

Jeremy
Tue Jan 03 17:22:14 CST 2006

"Don Burn" <burn@stopspam.acm.org> wrote in message
news:%23sqT%23pHEGHA.3868@TK2MSFTNGP09.phx.gbl...
> Only thing I can think of is see who the culprit is, then see if you can
> live without the driver that is issuing the call.
>

Thanks, I've tracked the assertions down to mrxvpc.sys which is the Virtual
Machine Folder Sharing Driver. There are no debug symbols for it so I can't
pin it down to a specific routine. A little more digging turned up some low
down on VPC extensions not working all that well with the checked builds of
Windows so it appears to be something I'll have to live with.

Thanks,
Jeremy Boschen