Workstations bluescreening

jdwall <jdwall@no-mx.forums.novell.com> wrote:

> I can get the additional parameters with the 0xC4 bugcheck, but where
> do I find out what they mean? At this point I don't have a specific
> driver as a potential culprit, I thought it was nicm.sys but I'll need
> to go back to the drawing board.

The WinDBG documentation has a fairly robust description of all the
bugcheck conditions. The same documentation is online at
http://msdn.microsoft.com/en-us/library/ms796113.aspx.

NICM acts as kind of an abstraction layer over the Windows kernel
services, so its very frequently in the call stack for Novell Client.

e.g. NWFS.SYS might effectively be calling some Windows kernel
service, but from a crash dump's perspective it's actually NICM.SYS
who ultimately makes the call on NWFS.SYS' behalf. So if there is a
crash during that call, NICM.SYS is who you see on the stack first
instead of NWFS.SYS.

In the case of having "deadlock detection" turned on, its the fact
that SRVLOC.SYS had called NICM.SYS to acquire/release a lock which
would be why a 0xC4 trap might occur citing NICM.SYS. Being selective
about which Driver Verifier features are enabled, and selecting only
"Special Pool", "Pool Tracking" and "IRQL Checking" would enable those
features useful for trying to catch memory corruption without allowing
the "deadlock detection" trap to get in your way.

Alan Adams
Novell Client CPR Group
alan.adams@novell.com

Novell
Making IT Work As One
www.novell.com

Upgrade to OES Community
http://www.novell.com/communities/co.../upgradetooes/