XP reboot executing from mapped drive

I am experiencing XP reboots when I attempt to execute a file stored in a
mapped drive, but only when using the Novell Client.  The machine in
question had been running XP Pro SP1 with Client 4.90 SP1 successfully for a
long time.  After updating to client 4.91 I ran for weeks without noticing a
problem.  When I applied XP SP2 I first noticed it, but I cannot say for
sure whether it was broken before I also added Mcafee Internet Security
Suite 2005.

I tried applying the 4.91 SP1, uninstallling the client and re-installing
4.90 SP1, removing Windows SP2, and disabling McAfee.  The problem remained.

The only way I have been able to eliminate the problem is to use the
Microsoft XP client for Netware, which is not an acceptable solution for
this particular machine as I had been using it to administer Netware file
rights with the Windows Explorer right click options.

Is it possible I need to run some kind of scrub to completely purge the 4.91
client and then re-install the 4.90 client?


0
Steven
9/11/2005 7:20:51 PM
novell.netware.winnt-2x-xp 10573 articles. 1 followers. Follow

6 Replies
395 Views

Similar Articles

[PageSpeed] 41

Steven,

Sounds like Windows is automatically rebooting after 
bug-checking/blue-screening.
You can disable the automatic reboot by going into Windows System 
properties, Advanced tab, Startup and Recovery, un-check Automatically 
reboot.
Can you isolate the issue to a particular file or process?

Event Viewer logs in Windows showing anything unusual?

Can you remove Mcafee Internet Security Suite 2005 one of its services or 
drivers is the cause?
Any other driver-based software like firewall, VPN, remote management or 
antivirus installed and running?

-- 
Tony Pedretti
TransUnion Corporation 


0
Tony
9/12/2005 6:59:08 PM
No blue screen, just a reboot.  The event log shows a bugcheck recovery:
0x1000007f (0x00000008, 0x80042000, 0x00000000, 0x00000000).

Microsoft error report says it is a device driver, of course

The only configuration change that makes a difference is switching from
Novell client to Microsoft client.  The problem occurs with any executable
file stored on a mapped drive.


0
Steven
9/13/2005 12:06:33 PM
I am new to Win dump analysis.  I looked at MS KB article 315271, and then
ran dumpchk.  But, I cannot find the Exceptions code or Exception address
that is shown in the article. Here is what I get.  Does something here take
the place of "Exception Address"?  I have the pstat.exe output, and am
trying to figure out which module has a problem.

Loading dump file mini091105-02.dmp
----- 32 bit Kernel Mini Dump Analysis

DUMP_HEADER32:
MajorVersion        0000000f
MinorVersion        00000a28
DirectoryTableBase  00039000
PfnDataBase         81c03000
PsLoadedModuleList  8054c150
PsActiveProcessHead 8054e1b8
MachineImageType    0000014c
NumberProcessors    00000002
BugCheckCode        1000007f
BugCheckParameter1  00000008
BugCheckParameter2  f771fd70
BugCheckParameter3  00000000
BugCheckParameter4  00000000
PaeEnabled          00000000
KdDebuggerDataBlock 8053c2e0
MiniDumpFields      00000dff

TRIAGE_DUMP32:
ServicePackBuild      00000100
SizeOfDump            00010000
ValidOffset           0000fffc
ContextOffset         00000320
ExceptionOffset       000007d0
MmOffset              00001068
UnloadedDriversOffset 000010a0
PrcbOffset            00001878
ProcessOffset         000024c8
ThreadOffset          00002720
CallStackOffset       00002978
SizeOfCallStack       00003000
DriverListOffset      00005c08
DriverCount           000000b3
StringPoolOffset      00009130
StringPoolSize        00001908
BrokenDriverOffset    00000000
TriageOptions         00000041
TopOfStack            af781000
DebuggerDataOffset    00005978
DebuggerDataSize      00000290
DataBlocksOffset      0000aa38
DataBlocksCount       00000003


Windows XP Kernel Version 2600 (Service Pack 1) MP (2 procs) Free x86
compatible

Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054c150
Debug session time: Sun Sep 11 13:57:27 2005
System Uptime: 0 days 0:07:26
start    end        module name
804d4000 806bb000   nt             Checksum: 001DBB33  Timestamp: Tue Mar 01
19:
36:33 2005 (42250A91)

Unloaded modules:
aed07000 aed2e000   kmixer.sys    Timestamp: unavailable (00000000)
f7a8e000 f7a8f000   drmkaud.sys    Timestamp: unavailable (00000000)
aed2e000 aed51000   aec.sys     Timestamp: unavailable (00000000)
aedb4000 aedc1000   DMusic.sys    Timestamp: unavailable (00000000)
aedd4000 aede2000   swmidi.sys    Timestamp: unavailable (00000000)
f79a3000 f79a5000   splitter.sys    Timestamp: unavailable (00000000)
af694000 af6a4000   Serial.SYS    Timestamp: unavailable (00000000)
f7727000 f772f000   processr.sys    Timestamp: unavailable (00000000)
baea1000 baea5000   kbdhid.sys    Timestamp: unavailable (00000000)
f77f7000 f77fc000   Cdaudio.SYS    Timestamp: unavailable (00000000)
f77ef000 f77f4000   Flpydisk.SYS    Timestamp: unavailable (00000000)
f77e7000 f77ee000   Fdc.SYS     Timestamp: unavailable (00000000)

Finished dump check


0
Steven
9/13/2005 1:16:26 PM
http://msdn.microsoft.com/library/en-us/ddtools/hh/ddtools/BCCodes_abf8ed0c-026f-4e8e-9104-2bdbc4cd024d.xml.asp
http://msdn.microsoft.com/library/en-us/ddtools/hh/ddtools/BCCodes_23082e55-3e4e-435f-b783-051a0ab3c1fa.xml.asp

UNEXPECTED_KERNEL_MODE_TRAP_M (0x1000007F) with the first parameter of
0x00000008 is a "double fault" (exception occurring within an
exception) and as documented is typically a kernel-mode stack
overflow.

At least one case where I experienced something like this was related
to a firewall installed on the machine.  i.e. The Novell Client would
have happily done its job, but the attempt to call TCPIP was
intercepted and the firewall started to do a bunch of work on the same
thread, ended up performing an operation that caused Windows to call
the Novell Client again (still on the same stack, but now deeper into
it), which ended up hitting another TCPIP call that the firewall
wanted to intercept, etc., until the kernel-mode stack was simply
exhausted.

Switching to the Microsoft Client for NetWare might affect this by
simply using slightly less stack (if the problem isn't pure
recursion), or it could be because the Microsoft client is never
calling TCPIP (since its IPX-only) and is therefore uninteresting to
the firewall.

But firewall is just an example; really any software intended to
filter (virus scanner, security or "workstation lock down" software,
etc.) could just as readily be intentionally intercepting something
that would have otherwise been interaction between the Novell Client
and Windows directly.

If you can't find any software that seems to fit that description
(i.e. some other package that when removed allows the workstation to
succeed even with the Novell Client present), probably the only thing
to really "do about it" is capture a memory dump and open a support
case with Novell.

DUMPCHK is mainly a tool for validating that a dump file isn't
corrupt.  One of the offline-capable debuggers included in the
Debugging Tools for Windows (such as WinDBG) would be the manner in
which to actually examine what the dump contains, as opposed to just
whether the dump file itself is valid.

http://www.microsoft.com/whdc/DevTools/Debugging/

"Steven Fitzgerald" <scfitzge@deletethis.telecominstitute.com> wrote:

> No blue screen, just a reboot.  The event log shows a bugcheck recovery:
> 0x1000007f (0x00000008, 0x80042000, 0x00000000, 0x00000000).
> 
> Microsoft error report says it is a device driver, of course
> 
> The only configuration change that makes a difference is switching from
> Novell client to Microsoft client.  The problem occurs with any executable
> file stored on a mapped drive.
> 

Alan Adams
alancrumbadams@drcrumb.com
(for email, remove the crumbs)
0
Alan
9/13/2005 2:55:57 PM
"At least one case where I experienced something like this was related
to a firewall installed on the machine"

It was the Mcafee personal firewall.  Removed it, all is well now on client 
4.91 SP1.  Thanks. 


0
Steven
9/22/2005 12:58:20 PM
Interesting.  Thanks for the post back to the newsgroup.

If it became critical for the firewall to function in concert with the
Novell Client, and the latest version of the McAfee firewall still
demonstrates the same issue, technically you could start by taking a
dump of the issue to either vendor.  (Novell or McAfee; whichever one
you have a better support relationship with for getting in the door.)

"Steven Fitzgerald" <scfitzge@deletethis.telecominstitute.com> wrote:

> "At least one case where I experienced something like this was related
> to a firewall installed on the machine"
> 
> It was the Mcafee personal firewall.  Removed it, all is well now on client 
> 4.91 SP1.  Thanks. 

Alan Adams
alancrumbadams@drcrumb.com
(for email, remove the crumbs)
0
Alan
9/22/2005 5:46:59 PM
Reply: