Debugging minidump; Problem with multiple laptops on network

First off, I am new here and am not positive this is in the right forum so just let me know or transfer it to the right area. I am working with a company that is up on a network with about 150 PC's and 40 laptops. About 7 of the laptops are having very similar problems with random blue screens. These laptops are either DELL 620's or 820's. I am hoping someone can point me in the right direction with the dump file debugged. The blue screens are mainly popping up right on start up, shutting down, or just randomly. It seems to occur even more often when I log onto administrator and when the laptop is on its replicator.

______________________________________________________________

Bugcheck Analysis:
BugCheck C2, {7, cd4, 1, 86d6f318}

Probably caused by : ntkrpamp.exe ( nt!ExFreePoolWithTag+2a3 )

Followup: MachineOwner
---------

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 00000001, Memory contents of the pool block
Arg4: 86d6f318, Address of the block of pool being deallocated

Debugging Details:
------------------


POOL_ADDRESS: 86d6f318

FREED_POOL_TAG: FMsl

BUGCHECK_STR: 0xc2_7_FMsl

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8054a583 to 804f9f13

STACK_TEXT:
f7a45810 8054a583 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x1b
f7a45860 80534ed0 86d6f318 00000000 80534e78 nt!ExFreePoolWithTag+0x2a3
f7a4587c f73fdb88 86e47e70 86c09e74 86e47e08 nt!ExDeleteResourceLite+0x58
f7a45890 f740e8df 86e47e08 e39f90d0 86e47e0c fltMgr!FltpReleaseStreamListCtrl+0x28
f7a458a8 8056da14 86e47e0c 00000000 f7a45930 fltMgr!DeleteStreamListCtrlCallback+0x67
f7a458f0 f7369f46 e39f90d0 e39f9008 e39f90d0 nt!FsRtlTeardownPerStreamContexts+0x52
f7a4590c f7352c30 86cff008 f7a40705 e39f9038 Ntfs!NtfsDeleteScb+0x165
f7a45924 f732d800 86cff008 e39f90d0 00000000 Ntfs!NtfsRemoveScb+0x88
f7a45940 f7352a17 86cff008 e39f9008 00000000 Ntfs!NtfsPrepareFcbForRemoval+0x52
f7a45988 f732d7b0 86cff008 e39f90d0 e39f9268 Ntfs!NtfsTeardownStructures+0x5b
f7a459b4 f73504b5 86cff008 009f90d0 e39f9268 Ntfs!NtfsDecrementCloseCounts+0x9e
f7a45a38 f7350254 86cff008 e39f90d0 e39f9008 Ntfs!NtfsCommonClose+0x397
f7a45ad8 804ef163 86f0d020 85f2be00 86f7e270 Ntfs!NtfsFsdClose+0x21f
f7a45ae8 f73e5459 f7a45b24 804ef163 86ee7c10 nt!IopfCallDriver+0x31
f7a45af0 804ef163 86ee7c10 85f2be00 85f2be00 sr!SrPassThrough+0x31
f7a45b00 f73fae9b 86f28438 85f2be00 86c68158 nt!IopfCallDriver+0x31
f7a45b24 f73fb06b f7a45b44 86f28438 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f7a45b5c 804ef163 86f28438 85f2be00 85f2be00 fltMgr!FltpDispatch+0x11f
f7a45b6c f73fae9b 86dfd8d8 85f2be00 86c09c18 nt!IopfCallDriver+0x31
f7a45b90 f73fb06b f7a45bb0 86dfd8d8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f7a45bc8 804ef163 86dfd8d8 85f2be00 85f2be00 fltMgr!FltpDispatch+0x11f
f7a45bd8 805828e0 86224b50 00000000 00000000 nt!IopfCallDriver+0x31
f7a45c10 805ba023 00224b68 00000000 86224b50 nt!IopDeleteFile+0x132
f7a45c2c 80525aca 86224b68 00000000 00000000 nt!ObpRemoveObjectRoutine+0xdf
f7a45c44 80509d0c 86cbb698 00000000 e2aac7e0 nt!ObfDereferenceObject+0x4c
f7a45c6c 8050a6c8 e2aac748 00000000 86cbb698 nt!MiSegmentDelete+0xec
f7a45d40 8050b3c9 00cbb698 00000000 806e4aa8 nt!MiCleanSection+0x750
f7a45d90 8050b4f8 00000000 86fbb020 00000000 nt!MiRemoveUnusedSegments+0x94f
f7a45dac 805cea08 00000000 00000000 00000000 nt!MiDereferenceSegmentThread+0x60
f7a45ddc 8054546e 8050b498 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExFreePoolWithTag+2a3
8054a583 8b45f8 mov eax,dword ptr [ebp-8]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExFreePoolWithTag+2a3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a

FAILURE_BUCKET_ID: 0xc2_7_FMsl_nt!ExFreePoolWithTag+2a3

BUCKET_ID: 0xc2_7_FMsl_nt!ExFreePoolWithTag+2a3

Followup: MachineOwner

________________________________________________________________

It is pointing to ntkrpamp.exe, but after researching I can not come up with a viable solution to fixing this problem. I read that sometimes this points to faulty RAM, is this possible? I am hoping to get some advice here and if you need any extra information please just reply.

 

I am having the exact same issue with about 4 Dell D830's.

BAD_POOL_CALLER (c2) and IRQL_NOT_LESS_OR_EQUAL (a)

Have you yet found a solution?

Here are my crash dumps:

Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_qfe.070227-2300
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Fri Jul 11 08:56:00.265 2008 (GMT-5)
System Uptime: 0 days 0:10:37.937
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details
Loading unloaded module list
.............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {4, 1c, 0, 804fceda}

PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details
Probably caused by : ntkrpamp.exe ( nt!KeReleaseSemaphore+14 )

Followup: MachineOwner
---------

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 0000001c, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 804fceda, address which referenced memory

Debugging Details:
------------------

PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details

READ_ADDRESS: 00000004

CURRENT_IRQL: 1c

FAULTING_IP:
nt!KeReleaseSemaphore+14
804fceda 8b5e04 mov ebx,dword ptr [esi+4]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: OUTLOOK.EXE

TRAP_FRAME: a9214578 -- (.trap 0xffffffffa9214578)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=80552882 edx=00000000 esi=00000000 edi=00001188
eip=804fceda esp=a92145ec ebp=a92145fc iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!KeReleaseSemaphore+0x14:
804fceda 8b5e04 mov ebx,dword ptr [esi+4] ds:0023:00000004=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 804fceda to 80543a70

STACK_TEXT:
a9214578 804fceda badb0d00 00000000 e11c0000 nt!KiTrap0E+0x238
a92145fc 80534b7b 00000000 00000000 00001188 nt!KeReleaseSemaphore+0x14
a921462c f733b81b a92147f4 a9214650 f733d400 nt!ExReleaseResourceLite+0x6f
a9214638 f733d400 a92147f4 e1151320 00000000 Ntfs!NtfsReleaseFcb+0x4e
a9214650 f733b417 a92147f4 00000000 a92147f4 Ntfs!NtfsReleaseAllResources+0x62
a9214668 f733b666 a92147f4 00000001 a92147f4 Ntfs!NtfsCleanupIrpContext+0x23
a9214680 f735efbc a92147f4 00000000 00000000 Ntfs!NtfsCompleteRequest+0x35
a92147d0 f735fe42 a92147f4 86434d50 a9214924 Ntfs!NtfsCommonCreate+0x19f4
a921497c f73e6f70 86434d50 a9214bfc 8649b020 Ntfs!NtfsNetworkOpenCreate+0x8a
a921499c f73f40e8 86434d50 a9214bfc 8654a6a0 sr!SrFastIoQueryOpen+0x40
a92149bc f7400927 000000f2 00000000 a92149f4 fltMgr!FltpPerformFastIoCall+0x300
a9214a14 80581ee6 86434d50 a9214bfc 8608eae8 fltMgr!FltpFastIoQueryOpen+0xa1
a9214b00 805bdf06 86546e30 00000000 8527d360 nt!IopParseDevice+0x916
a9214b78 805ba58e 00000000 a9214bb8 00000040 nt!ObpLookupObjectName+0x53c
a9214bcc 8057602f 00000000 00000000 865ba301 nt!ObOpenObjectByName+0xea
a9214d54 805409ac 0013d304 0013d2cc 0013d330 nt!NtQueryFullAttributesFile+0x121
a9214d54 7c90eb94 0013d304 0013d2cc 0013d330 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0013d330 00000000 00000000 00000000 00000000 0x7c90eb94


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeReleaseSemaphore+14
804fceda 8b5e04 mov ebx,dword ptr [esi+4]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!KeReleaseSemaphore+14

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a

FAILURE_BUCKET_ID: 0xA_nt!KeReleaseSemaphore+14

BUCKET_ID: 0xA_nt!KeReleaseSemaphore+14

Followup: MachineOwner
---------

Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_qfe.070227-2300
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Thu Jul 10 13:49:04.640 2008 (GMT-5)
System Uptime: 0 days 0:06:38.328
Loading Kernel Symbols
..................................................................................................................................................
Loading User Symbols

Loading unloaded module list
...............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck C2, {7, cd4, 1, 85ff6bc8}

Probably caused by : ntkrpamp.exe ( nt!ExFreePoolWithTag+2a3 )

Followup: MachineOwner
---------

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

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 00000001, Memory contents of the pool block
Arg4: 85ff6bc8, Address of the block of pool being deallocated

Debugging Details:
------------------


POOL_ADDRESS: 85ff6bc8 Nonpaged pool

FREED_POOL_TAG: FMsl

BUGCHECK_STR: 0xc2_7_FMsl

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from 8054a583 to 804f9f13

STACK_TEXT:
a9369ac0 8054a583 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x1b
a9369b10 80534ed0 85ff6bc8 00000000 80534e78 nt!ExFreePoolWithTag+0x2a3
a9369b2c f73f7b88 8532e778 86044cdc 8532e710 nt!ExDeleteResourceLite+0x58
a9369b40 f74088df 8532e710 e12050d0 8532e714 fltMgr!FltpReleaseStreamListCtrl+0x28
a9369b58 8056da14 8532e714 00000000 a9369be0 fltMgr!DeleteStreamListCtrlCallback+0x67
a9369ba0 f7379f46 e12050d0 e1205008 e12050d0 nt!FsRtlTeardownPerStreamContexts+0x52
a9369bbc f7362c30 857b0278 a9360705 e1205038 Ntfs!NtfsDeleteScb+0x165
a9369bd4 f733d800 857b0278 e12050d0 00000000 Ntfs!NtfsRemoveScb+0x88
a9369bf0 f7362a17 857b0278 e1205008 00000000 Ntfs!NtfsPrepareFcbForRemoval+0x52
a9369c38 f733d7b0 857b0278 e12050d0 00000000 Ntfs!NtfsTeardownStructures+0x5b
a9369c64 f73604b5 857b0278 002050d0 00000000 Ntfs!NtfsDecrementCloseCounts+0x9e
a9369ce8 f73653e3 857b0278 e12050d0 e1205008 Ntfs!NtfsCommonClose+0x397
a9369d7c 80537aff 00000000 00000000 85e77da8 Ntfs!NtfsFspClose+0xe3
a9369dac 805cea08 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
a9369ddc 8054546e 80537a10 80000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExFreePoolWithTag+2a3
8054a583 8b45f8 mov eax,dword ptr [ebp-8]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExFreePoolWithTag+2a3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a

FAILURE_BUCKET_ID: 0xc2_7_FMsl_nt!ExFreePoolWithTag+2a3

BUCKET_ID: 0xc2_7_FMsl_nt!ExFreePoolWithTag+2a3

Followup: MachineOwner
---------

 

We did find a solution for our problem. My company uses TrendMicro for virus protection on all the computers, but a different version for laptops. There was a bug in this version, which was affecting our New York and San Antonio offices. TrendMicro was contacted and eventually we got a patch out of them. Since the update we have not seen any of the reoccuring problems. If you are using TrendMicro please let me know and I will direct you to the patch.

 

Yes, we are using Trend Micro Internet Security 2008. If this patch resolves the issues I'll have one good weekend... Your help is much appreciated!

 

This is the link to the patch they sent:
http://rapidshare.com/files/87620688/TrendMicro_TIS_16.05_1015_x32.rar

Before they sent the patch we received these steps, some of the computers worked successfully after just as a second solution.

Hope this helps; let me know your results.

1. Open the Registry Editor (regedit.exe).
Click start > Run > Type in regedit > click ok

2. Go to HKEY_LOCAL_MACNE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.

3. Look for the "PagedPoolSize" key and change its value from “0”to "FFFFFFFF".

4. Reboot the server/computer.


Option 2: Enable SystemMapView

1. Open the Registry Editor (regedit.exe).
Click start > Run > Type in regedit > click ok

2. Go to HKEY_LOCAL_MACNE\SYSTEM\CurrentControlSet\Services\VSApiNt\Parameters. [At first you won’t see any Parameters folder so you need to create it]

3. Add a new DWORD value called "EnableSystemView" then assign it a value of "1".

4. Reboot the server/computer.

 

Got it. I'll give this a shot. I spoke with Trend, but they said were unaware of any issues... Typical.

I'll cross my fingers!!!

Thanks much!