Frans,
Thanks for your reply - here's what I get from the MEMORY DUMP file:
Microsoft (R) Windows Debugger Version 6.3.0011.2
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINNT\MEMORY .DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is: C:\WINNT\Symbol s
Executable search path is: C:\Program
Files\BIDMC\Pmr i\PmriBatchProc essor.exe
Windows 2000 Kernel Version 2195 (Service Pack 4) UP Free x86
compatible
Product: Server, suite: Enterprise TerminalServer
Kernel base = 0x80400000 PsLoadedModuleL ist = 0x8046e1b8
Debug session time: Tue Apr 13 17:08:15 2004
System Uptime: 1 days 8:58:38.161
Loading Kernel Symbols
............... ............... ............... ............... ............... ............... ..............
Loading unloaded module list
........
Loading User Symbols
............... .
*************** *************** *************** *************** *************** ****
*
*
* Bugcheck Analysis
*
*
*
*************** *************** *************** *************** *************** ****
Use !analyze -v to get detailed debugging information.
BugCheck 24, {19025e, bbd9c47c, bbd9c0d4, bfe83e99}
*** WARNING: symbols timestamp is wrong 0x3ede6e95 0x3ebc05a5 for
Ntfs.sys
*** WARNING: symbols timestamp is wrong 0x3f302c32 0x3ef274dc for
KERNEL32.dll
*** WARNING: Unable to verify checksum for wrshdsp.exe
*** ERROR: Module load completed but symbols could not be loaded for
wrshdsp.exe
Probably caused by : Unknown_Image
*** Followup info cannot be found !!! Please contact "Debugger Team"
---------
kd> !analyze -v
*************** *************** *************** *************** *************** ****
*
*
* Bugcheck Analysis
*
*
*
*************** *************** *************** *************** *************** ****
NTFS_FILE_SYSTE M (24)
If you see NtfsExceptionFi lter on the stack then the 2nd and 3rd
parameters are the exception record and context record. Do a .cxr
on the 3rd parameter and then kb to obtain a more informative
stack
trace.
Arguments:
Arg1: 0019025e
Arg2: bbd9c47c
Arg3: bbd9c0d4
Arg4: bfe83e99
Debugging Details:
------------------
EXCEPTION_RECOR D: bbd9c47c -- (.exr ffffffffbbd9c47 c)
ExceptionAddres s: bfe83e99
(Ntfs!NtfsDelet eAllocationInte rnal+0x00000784 )
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameter s: 2
Parameter[0]: 00000000
Parameter[1]: 0165c803
Attempt to read from address 0165c803
CONTEXT: bbd9c0d4 -- (.cxr ffffffffbbd9c0d 4)
eax=872ed0f8 ebx=db898430 ecx=bbd9c804 edx=bbd9c7f4 esi=bbd9c7f4
edi=75ff1470
eip=bfe83e99 esp=bbd9c544 ebp=bbd9c560 iopl=0 nv up ei ng nz
na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010282
Ntfs!NtfsDelete AllocationInter nal+0x784:
bfe83e99 6389ffff8b45 arpl [ecx+0x458bffff],ecx
ds:0023:0165c80 3=????????
Resetting default scope
DEFAULT_BUCKET_ ID: DRIVER_FAULT
BUGCHECK_STR: 0x24
LAST_CONTROL_TR ANSFER: from bfe87b9b to bfe83e99
STACK_TEXT:
bbd9c560 bfe87b9b 864ab388 e15be008 00000058
Ntfs!NtfsDelete AllocationInter nal+0x784
bbd9c724 bfe8478b 864ab388 e15be0d8 bbd9c7f4
Ntfs!NtfsCheckp ointAllVolumes+ 0x1a1
bbd9c83c bfe5ec66 864ab388 864f4b28 e15be0d8
Ntfs!NtfsCommon FlushBuffers+0x 69
bbd9cbcc bfe5d33e 864ab388 86923b48 872ed020
Ntfs!NtfsProces sException+0x1b f
bbd9cc34 8041fb8b 872ed020 86923b48 86923b48
Ntfs!NtfsDecrem entCloseCounts+ 0xaf
bbd9cc5c 80499b39 872ed020 86923b48 864f4b28 nt!IopfCallDriv er+0x35
bbd9cc5c 80499b39 872ed020 86923b48 864f4b28 nt!NtWriteFile+ 0x67a
bbd9cd38 80465691 00000358 00000000 00000000 nt!NtWriteFile+ 0x67a
bbd9cd38 77f823b2 00000358 00000000 00000000 nt!KiSystemServ ice+0xc4
00226774 7c5863ad 00000358 00000000 00000000 ntdll!NtWriteFi le+0xb
002267e0 0040df99 00000358 00226820 00000200
KERNEL32!GetCom puterNameA+0xd5
WARNING: Stack unwind information not available. Following frames may
be wrong.
00226800 0040d69e 00000358 00226820 00000200 wrshdsp+0xdf99
0022af54 0040b335 00000000 00228820 00000000 wrshdsp+0xd69e
0022af90 00409fdf 00000000 00000114 ffffffff wrshdsp+0xb335
0022bd98 004050b2 0022ddd8 00000114 ffffffff wrshdsp+0x9fdf
0022ff80 00413ff6 00000003 00000114 008a2798 wrshdsp+0x50b2
0022ffc0 7c5987e7 00000000 00000000 7ffdf000 wrshdsp+0x13ff6
0022fff0 00000000 00413f31 00000000 000000c8 KERNEL32!`strin g'+0xf
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE _TIMESTAMP: 0
STACK_COMMAND: .cxr ffffffffbbd9c0d 4 ; kb
BUCKET_ID: 0x24
*** Followup info cannot be found !!! Please contact "Debugger Team"
Does anything point you to a particular direction?
"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l> wrote in message news:<Xn******* *************** ***********@207 .46.248.16>...
the BSOD has a stop error listed as well as the kernel module in which the
stop occured. 10 to 1 it's a network driver malfunction. Please try to
update your drivers.
If you're running win98/me on the client, upgrade to winxp
FB
sh*******@yahoo .com (Shmulik) wrote in
news:c2******** *************** ***@posting.goo gle.com:
I have an application written in C# that creates a queue of items to
process, connects via a TCP connection to a server on a Unix box, and
then passes data files to the Unix box for processing (cluster) -
normally this works fine. However, on the front end, another Unix
system generates and transfers files to the DotNet application
(Management system/controller) and recently I've witnessed the
following:
1) Unix Box "A" generates data files and transfers them (RCP) to the
Windows DotNet box to a directory that the DotNet box watches for
changes.
2) The DotNet box "B" updates a local database, generates some
processing instructions, adds the information to a local queue and
then when a connection can be made to the the Unix Cluster (periodic
polling), the current item is popped from the queue and the requisite
data files are transferred to the Cluster for processing.
3) While the Cluster "C" is processing, the DotNet box "B" is
watching on one thread for new files to come in and on another thread
it periodically polls the Cluster "C" to see if it is available to
receive more files.
I've seen several times that after the DotNet box has transferred
files to the cluster and new files are being transferred from Box "A",
the DotNet box Blue screens - what should I be looking at - there is
little processing going on the DotNet box - mainly it acts as a data
transfer/maangement cop.
What should I be looking for?
TIA