Ignoring kernel assertions in Windbg

Please excuse me if this has been asked before – but I did a search on
the website and couldn’t find an answer. I’m also fairly new to
Windbg/driver development.

Anyway, I’m running a checked build of server 2003 and getting hit by
the same asserts over and over and over again. When prompted what to
do, I choose ‘i’ for ‘Ignore,’ but that doesn’t seem to do anything.
The assert keeps triggering. Mucking around in the Windbg docs hasn’t
helped much either.

Any tips/help would be appreciated. Thanks.

I get very few asserts from the checked build. Have you looked at these and
seen if they are comming from actions by your code? The only asserts I see
are the Intel ethernet driver on startup, or mistakes I have made.


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

“Lou Arruda” wrote in message news:xxxxx@windbg…
> Please excuse me if this has been asked before – but I did a search on
> the website and couldn’t find an answer. I’m also fairly new to
> Windbg/driver development.
>
> Anyway, I’m running a checked build of server 2003 and getting hit by
> the same asserts over and over and over again. When prompted what to
> do, I choose ‘i’ for ‘Ignore,’ but that doesn’t seem to do anything.
> The assert keeps triggering. Mucking around in the Windbg docs hasn’t
> helped much either.
>
> Any tips/help would be appreciated. Thanks.
>

In article , Don Burn wrote:
> I get very few asserts from the checked build. Have you looked at these and
> seen if they are comming from actions by your code? The only asserts I see
> are the Intel ethernet driver on startup, or mistakes I have made.

These asserts aren’t coming up from my code. Actually, it appears as if
they are coming from McAfee VirusShield’s FS filter driver’s calls into
the Rtl. I temporarily disabled McAfee and the problem has gone away,
but if there was some way I can ignore asserts in the future (in case IT
really comes down hard on me for disabling McAfee), that would be
preferable.



-------------------- http://www.techhouse.org/lou ----------------------
xxxxx@TealStudios.com | “Searching for a distant star, heading off to
“Dragonmaster Lou” | Iscandar, leaving all we love behind, who knows
Tech House Alum | what dangers we’ll find…”
-----------------------------------------------------------------------

Oh… THAT assert failure – it’s been seen and reported many times to the
best of my knowledge; all we have to do now is persuade McAfee to fix their
bug…

For the moment, your only choice is to disable on-access scanning when
running the checked kernel…

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lou Arruda
Sent: Wednesday, April 13, 2005 3:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Ignoring kernel assertions in Windbg

In article , Don Burn wrote:
> I get very few asserts from the checked build. Have you looked at these
and
> seen if they are comming from actions by your code? The only asserts I
see
> are the Intel ethernet driver on startup, or mistakes I have made.

These asserts aren’t coming up from my code. Actually, it appears as if
they are coming from McAfee VirusShield’s FS filter driver’s calls into
the Rtl. I temporarily disabled McAfee and the problem has gone away,
but if there was some way I can ignore asserts in the future (in case IT
really comes down hard on me for disabling McAfee), that would be
preferable.



-------------------- http://www.techhouse.org/lou ----------------------
xxxxx@TealStudios.com | “Searching for a distant star, heading off to
“Dragonmaster Lou” | Iscandar, leaving all we love behind, who knows
Tech House Alum | what dangers we’ll find…”
-----------------------------------------------------------------------


You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I usually do something like this:
Sxe -c "j (@$ip=0x

) 'g' ; ''"

Where is the IP of what you want to skip, and is the
event type for why the debugger is breaking in. Sometimes I'll home it
in on a different frame by doing something like (using '.frame /r #' to
get the IP to use in ):
Sxe -c ".frame 4;j (@$scopeip=0x) 'g' ; ''"

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Graham, Simon
Sent: Wednesday, April 13, 2005 12:44 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Ignoring kernel assertions in Windbg

Oh... THAT assert failure -- it's been seen and reported many times to
the
best of my knowledge; all we have to do now is persuade McAfee to fix
their
bug...

For the moment, your only choice is to disable on-access scanning when
running the checked kernel...

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lou Arruda
Sent: Wednesday, April 13, 2005 3:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Ignoring kernel assertions in Windbg

In article , Don Burn wrote:
> I get very few asserts from the checked build. Have you looked at
these
and
> seen if they are comming from actions by your code? The only asserts
I
see
> are the Intel ethernet driver on startup, or mistakes I have made.

These asserts aren't coming up from my code. Actually, it appears as if
they are coming from McAfee VirusShield's FS filter driver's calls into
the Rtl. I temporarily disabled McAfee and the problem has gone away,
but if there was some way I can ignore asserts in the future (in case IT
really comes down hard on me for disabling McAfee), that would be
preferable.

--

-------------------- http://www.techhouse.org/lou ----------------------
xxxxx@TealStudios.com | "Searching for a distant star, heading off to
"Dragonmaster Lou" | Iscandar, leaving all we love behind, who knows
Tech House Alum | what dangers we'll find..."
-----------------------------------------------------------------------

---
You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Neat! Hey Jason - do you offer courses in advanced debugger scripting?? :wink:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jason Shay
Sent: Wednesday, April 13, 2005 4:53 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Ignoring kernel assertions in Windbg

I usually do something like this:
Sxe -c "j (@$ip=0x

) 'g' ; ''"

Where is the IP of what you want to skip, and is the
event type for why the debugger is breaking in. Sometimes I'll home it
in on a different frame by doing something like (using '.frame /r #' to
get the IP to use in ):
Sxe -c ".frame 4;j (@$scopeip=0x) 'g' ; ''"

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Graham, Simon
Sent: Wednesday, April 13, 2005 12:44 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Ignoring kernel assertions in Windbg

Oh... THAT assert failure -- it's been seen and reported many times to
the
best of my knowledge; all we have to do now is persuade McAfee to fix
their
bug...

For the moment, your only choice is to disable on-access scanning when
running the checked kernel...

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lou Arruda
Sent: Wednesday, April 13, 2005 3:35 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Ignoring kernel assertions in Windbg

In article , Don Burn wrote:
> I get very few asserts from the checked build. Have you looked at
these
and
> seen if they are comming from actions by your code? The only asserts
I
see
> are the Intel ethernet driver on startup, or mistakes I have made.

These asserts aren't coming up from my code. Actually, it appears as if
they are coming from McAfee VirusShield's FS filter driver's calls into
the Rtl. I temporarily disabled McAfee and the problem has gone away,
but if there was some way I can ignore asserts in the future (in case IT
really comes down hard on me for disabling McAfee), that would be
preferable.

--

-------------------- http://www.techhouse.org/lou ----------------------
xxxxx@TealStudios.com | "Searching for a distant star, heading off to
"Dragonmaster Lou" | Iscandar, leaving all we love behind, who knows
Tech House Alum | what dangers we'll find..."
-----------------------------------------------------------------------

---
You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

---
You are currently subscribed to windbg as: unknown lmsubst tag argument: ''
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jason Shay wrote:

I usually do something like this:
Sxe -c "j (@$ip=0x

) 'g' ; ''"
>
>Where is the IP of what you want to skip, and is the
>event type for why the debugger is breaking in. Sometimes I'll home it
>in on a different frame by doing something like (using '.frame /r #' to
>get the IP to use in ):
> Sxe -c ".frame 4;j (@$scopeip=0x) 'g' ; ''"
>
>

Magic. Have you ever considered a lucrative career as a Perl coder?

--
- Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hello All,

It is, of course, interesting trick but it seems to me that documented
command “ah” can produce the same results. Is not it?

Best regards,
Oleksiy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, April 13, 2005 11:18 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Ignoring kernel assertions in Windbg

Jason Shay wrote:

>I usually do something like this:
> Sxe -c "j (@$ip=0x

) 'g' ; ''"
> >
> >Where is the IP of what you want to skip, and
> is the
> >event type for why the debugger is breaking in. Sometimes
> I'll home it
> >in on a different frame by doing something like (using
> '.frame /r #' to
> >get the IP to use in ):
> > Sxe -c ".frame 4;j (@$scopeip=0x) 'g' ; ''"
> >
> >
>
> Magic. Have you ever considered a lucrative career as a Perl coder?
>
> --
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> ---
> You are currently subscribed to windbg as: xxxxx@nero.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

Brilliant! And yes, assuming that the which you are trying to
ignore actually comes in as ‘asrt’, the ah command looks better. From
my personal experience (hanging out in user-land), I find I usually need
to ignore the ‘bpe’ event.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Oleksiy Shatylo
Sent: Thursday, April 14, 2005 1:39 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Ignoring kernel assertions in Windbg

Hello All,

It is, of course, interesting trick but it seems to me that documented
command “ah” can produce the same results. Is not it?

Best regards,
Oleksiy
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Wednesday, April 13, 2005 11:18 PM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] Ignoring kernel assertions in Windbg
>
> Jason Shay wrote:
>
> >I usually do something like this:
> > Sxe -c “j (@$ip=0x) ‘g’ ; ‘’”
> >
> >Where is the IP of what you want to skip, and
> is the
> >event type for why the debugger is breaking in. Sometimes
> I’ll home it
> >in on a different frame by doing something like (using
> ‘.frame /r #’ to
> >get the IP to use in ):
> > Sxe -c “.frame 4;j (@$scopeip=0x) ‘g’ ; ‘’”
> >
> >
>
> Magic. Have you ever considered a lucrative career as a Perl coder?
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@nero.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com