Verifier bugchecks on NAVAP.sys

NTDEV
1

Hi,

My XPsp2 system bugchecks when I enabled DV on *MY* driver. However, it’s
not complaining mine but NAVAP.sys. It crashes even my driver is not loaded
so it’s pretty safe to assume my driver is not at fault.

I’ve never used NAV before (I used NAI). I have searched the archive knowing
that NAV switching stack can cause the problem. Has NAV fixed this already?
Or do they have a plan to fix it? Or is there a way to tell NAV not to
switch stack? Any NAV developer is listening?

I need to verifier my code with deadlock detection on, I also want to have
my system protected from virus attack at the same time. But NAV is the
default installation for all PCs here.

Thanks,
Calvin

–
Calvin Guan Windows DDK MVP
Staff SW Engineer, NetXtreme MINIPORT
Enterprise Network Controller Engineering
Broadcom Corporation www.broadcom.com

1: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a ‘!deadlock’ KD command to get more information.
Arguments:
Arg1: 00000090, A driver switched stacks. The current stack is neither a
thread
stack nor a DPC stack. Typically the driver doing this should be
on the stack obtained from `kb’ command.
Arg2: f771f120
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0xc4_90

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0

STACK_TEXT:
85dd29d8 804f428c 00000003 85dd2d08 00000090
nt!RtlpBreakWithStatusInstruction
85dd2a24 804f4d11 00000003 85e12280 00000000 nt!KiBugCheckDebugBreak+0x19
85dd2df0 804f52af 000000c4 00000090 f771f120 nt!KeBugCheck2+0x46d
85dd2e10 8063ab77 000000c4 00000090 f771f120 nt!KeBugCheckEx+0x19
85dd2e2c 8063ae47 8063b3db 00000000 00000000
nt!ViDeadlockCheckStackLimits+0x6b
85dd2e30 8063b3db 00000000 00000000 00000000 nt!ViDeadlockCanProceed+0x25
85dd2e54 80538367 85e12288 00000020 85ef8408
nt!VfDeadlockDeleteMemoryRange+0x11
85dd2e90 80525ebc 85e12288 00000000 85eb7da8 nt!ExFreePoolWithTag+0x95
85dd2ec0 80526215 85dd2ed8 f76469a0 f764689c nt!ExpFindCurrentThread+0x184
85dd2ee4 f323d05b f32641ac 00000000 f764689c
nt!ExAcquireResourceSharedLite+0x4f
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000410 00000000 00000000 00000000 00000000 NAVAP+0x105b

FOLLOWUP_IP:
NAVAP+105b
f323d05b 0fb6c0 movzx eax,al

SYMBOL_STACK_INDEX: a

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: NAVAP+105b

MODULE_NAME: NAVAP

IMAGE_NAME: NAVAP.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d00fca2

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0xc4_90_NAVAP+105b

BUCKET_ID: 0xc4_90_NAVAP+105b

Followup: MachineOwner

2

Isn’t it fun?

No, they have not fixed this problem, as far as the latest drop and I
suspect that this will not be fixed anytime soon.

The only way I have found to get around this is to disable the driver in the
registry.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Monday, June 20, 2005 12:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Verifier bugchecks on NAVAP.sys

Hi,

My XPsp2 system bugchecks when I enabled DV on *MY* driver. However, it’s
not complaining mine but NAVAP.sys. It crashes even my driver is not loaded
so it’s pretty safe to assume my driver is not at fault.

I’ve never used NAV before (I used NAI). I have searched the archive knowing
that NAV switching stack can cause the problem. Has NAV fixed this already?
Or do they have a plan to fix it? Or is there a way to tell NAV not to
switch stack? Any NAV developer is listening?

I need to verifier my code with deadlock detection on, I also want to have
my system protected from virus attack at the same time. But NAV is the
default installation for all PCs here.

Thanks,
Calvin

–
Calvin Guan Windows DDK MVP
Staff SW Engineer, NetXtreme MINIPORT
Enterprise Network Controller Engineering
Broadcom Corporation www.broadcom.com

1: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
Typically the code is 0x1001 (deadlock detected) and you can
issue a ‘!deadlock’ KD command to get more information.
Arguments:
Arg1: 00000090, A driver switched stacks. The current stack is neither a
thread
stack nor a DPC stack. Typically the driver doing this should be
on the stack obtained from `kb’ command.
Arg2: f771f120
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0xc4_90

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0

STACK_TEXT:
85dd29d8 804f428c 00000003 85dd2d08 00000090
nt!RtlpBreakWithStatusInstruction
85dd2a24 804f4d11 00000003 85e12280 00000000 nt!KiBugCheckDebugBreak+0x19
85dd2df0 804f52af 000000c4 00000090 f771f120 nt!KeBugCheck2+0x46d
85dd2e10 8063ab77 000000c4 00000090 f771f120 nt!KeBugCheckEx+0x19
85dd2e2c 8063ae47 8063b3db 00000000 00000000
nt!ViDeadlockCheckStackLimits+0x6b
85dd2e30 8063b3db 00000000 00000000 00000000 nt!ViDeadlockCanProceed+0x25
85dd2e54 80538367 85e12288 00000020 85ef8408
nt!VfDeadlockDeleteMemoryRange+0x11
85dd2e90 80525ebc 85e12288 00000000 85eb7da8 nt!ExFreePoolWithTag+0x95
85dd2ec0 80526215 85dd2ed8 f76469a0 f764689c nt!ExpFindCurrentThread+0x184
85dd2ee4 f323d05b f32641ac 00000000 f764689c
nt!ExAcquireResourceSharedLite+0x4f
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000410 00000000 00000000 00000000 00000000 NAVAP+0x105b

FOLLOWUP_IP:
NAVAP+105b
f323d05b 0fb6c0 movzx eax,al

SYMBOL_STACK_INDEX: a

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: NAVAP+105b

MODULE_NAME: NAVAP

IMAGE_NAME: NAVAP.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3d00fca2

STACK_COMMAND: kb

FAILURE_BUCKET_ID: 0xc4_90_NAVAP+105b

BUCKET_ID: 0xc4_90_NAVAP+105b

Followup: MachineOwner

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

I have had to completely uninstall NIS/NAV to update/install. I don’t allow
Norton of any flavor on my test mules, and just recently abandoned them
altogether for NOD32.

–
The personal opinion of
Gary G. Little

“Peter Scott” wrote in message
news:xxxxx@ntdev…
>
> Isn’t it fun?
>
> No, they have not fixed this problem, as far as the latest drop and I
> suspect that this will not be fixed anytime soon.
>
> The only way I have found to get around this is to disable the driver in
> the
> registry.
>
> Pete
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
> Sent: Monday, June 20, 2005 12:21 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Verifier bugchecks on NAVAP.sys
>
> Hi,
>
> My XPsp2 system bugchecks when I enabled DV on MY driver. However, it’s
> not complaining mine but NAVAP.sys. It crashes even my driver is not
> loaded
> so it’s pretty safe to assume my driver is not at fault.
>
> I’ve never used NAV before (I used NAI). I have searched the archive
> knowing
> that NAV switching stack can cause the problem. Has NAV fixed this
> already?
> Or do they have a plan to fix it? Or is there a way to tell NAV not to
> switch stack? Any NAV developer is listening?
>
> I need to verifier my code with deadlock detection on, I also want to have
> my system protected from virus attack at the same time. But NAV is the
> default installation for all PCs here.
>
>
> Thanks,
> Calvin
>
> –
> Calvin Guan Windows DDK MVP
> Staff SW Engineer, NetXtreme MINIPORT
> Enterprise Network Controller Engineering
> Broadcom Corporation www.broadcom.com
>
> 1: kd> !analyze -v
> *************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *************************************************************************
>
>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught. This is
> because the driver was specified in the registry as being suspect (by the
> administrator) and the kernel has enabled substantial checking of this
> driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
> will
> be among the most commonly seen crashes.
> Parameter 1 = 0x1000 … 0x1020 - deadlock verifier error codes.
> Typically the code is 0x1001 (deadlock detected) and you can
> issue a ‘!deadlock’ KD command to get more information.
> Arguments:
> Arg1: 00000090, A driver switched stacks. The current stack is neither a
> thread
> stack nor a DPC stack. Typically the driver doing this should be
> on the stack obtained from `kb’ command.
> Arg2: f771f120
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0xc4_90
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0
>
> STACK_TEXT:
> 85dd29d8 804f428c 00000003 85dd2d08 00000090
> nt!RtlpBreakWithStatusInstruction
> 85dd2a24 804f4d11 00000003 85e12280 00000000 nt!KiBugCheckDebugBreak+0x19
> 85dd2df0 804f52af 000000c4 00000090 f771f120 nt!KeBugCheck2+0x46d
> 85dd2e10 8063ab77 000000c4 00000090 f771f120 nt!KeBugCheckEx+0x19
> 85dd2e2c 8063ae47 8063b3db 00000000 00000000
> nt!ViDeadlockCheckStackLimits+0x6b
> 85dd2e30 8063b3db 00000000 00000000 00000000 nt!ViDeadlockCanProceed+0x25
> 85dd2e54 80538367 85e12288 00000020 85ef8408
> nt!VfDeadlockDeleteMemoryRange+0x11
> 85dd2e90 80525ebc 85e12288 00000000 85eb7da8 nt!ExFreePoolWithTag+0x95
> 85dd2ec0 80526215 85dd2ed8 f76469a0 f764689c nt!ExpFindCurrentThread+0x184
> 85dd2ee4 f323d05b f32641ac 00000000 f764689c
> nt!ExAcquireResourceSharedLite+0x4f
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> 00000410 00000000 00000000 00000000 00000000 NAVAP+0x105b
>
>
> FOLLOWUP_IP:
> NAVAP+105b
> f323d05b 0fb6c0 movzx eax,al
>
> SYMBOL_STACK_INDEX: a
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: NAVAP+105b
>
> MODULE_NAME: NAVAP
>
> IMAGE_NAME: NAVAP.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3d00fca2
>
> STACK_COMMAND: kb
>
> FAILURE_BUCKET_ID: 0xc4_90_NAVAP+105b
>
> BUCKET_ID: 0xc4_90_NAVAP+105b
>
> Followup: MachineOwner
> ---------
>
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

4

Hi Gary,

I also have “uninstalled” NAV so I can get Verifier to work, but I
really don’t like leaving a machine open like this (and neither would
our IS dept. if they knew…). Have you had any problems with NOD32 and
verifier or the checked version of the kernel? If not, I’ll have to
look into purchasing a copy for my victim box.

Thanks!
-Mike

Gary G. Little wrote:

I have had to completely uninstall NIS/NAV to update/install. I don’t allow
Norton of any flavor on my test mules, and just recently abandoned them
altogether for NOD32.

5

Simplest solution to that is unplug the network from the “victim”, unless
your testing requires the network and then you’re back to square one.

I find I like NOD32 after using it for a few months on all of my machines.
It manages to do something that Symantec has never been able to figure out
… do it’s job and stay our of your way. With NIS installed, I had Micrsoft
Updates that failed to install, and some of those were security holes that
NIS did not cover. All in all, life has become MUCH simpler since I dumped
NIS (Norton Internet Security).

NOD32 has the Little stamp of approval. :slight_smile:

–
The personal opinion of
Gary G. Little

“Michael Becker” wrote in message news:xxxxx@ntdev…
> Hi Gary,
>
> I also have “uninstalled” NAV so I can get Verifier to work, but I really
> don’t like leaving a machine open like this (and neither would our IS
> dept. if they knew…). Have you had any problems with NOD32 and verifier
> or the checked version of the kernel? If not, I’ll have to look into
> purchasing a copy for my victim box.
>
> Thanks!
> -Mike
>
>
> Gary G. Little wrote:
>
>>I have had to completely uninstall NIS/NAV to update/install. I don’t
>>allow Norton of any flavor on my test mules, and just recently abandoned
>>them altogether for NOD32.
>>
>>
>

6

Simplest solution to that is unplug the network from the “victim”, unless
your testing requires the network and then you’re back to square one.

I find I like NOD32 after using it for a few months on all of my machines.
It manages to do something that Symantec has never been able to figure out
… do it’s job and stay our of your way. With NIS installed, I had Micrsoft
Updates that failed to install, and some of those were for security holes
that
NIS did not cover. All in all, life has become MUCH simpler since I dumped
NIS (Norton Internet Security).

NOD32 has the Little stamp of approval. :slight_smile:

–
The personal opinion of
Gary G. Little

“Michael Becker” wrote in message news:xxxxx@ntdev…
> Hi Gary,
>
> I also have “uninstalled” NAV so I can get Verifier to work, but I really
> don’t like leaving a machine open like this (and neither would our IS
> dept. if they knew…). Have you had any problems with NOD32 and verifier
> or the checked version of the kernel? If not, I’ll have to look into
> purchasing a copy for my victim box.
>
> Thanks!
> -Mike
>
>
> Gary G. Little wrote:
>
>>I have had to completely uninstall NIS/NAV to update/install. I don’t
>>allow Norton of any flavor on my test mules, and just recently abandoned
>>them altogether for NOD32.
>>
>>
>