Windows Server SystemPost your Windows Server System question here. Besides Windows Server 2003, Windows Server System also includes other Microsoft Server software (such as BizTalk Server, Exchange Server, ISA Server & others).
Mission Statement
WindowsBBS is an online community dedicated to easily accessible technical support for those using Microsoft operating systems and other Windows software.
Our goal is to become the leading resource for computer users that require assistance with their day-to-day computer usage, including full support for networking PC's, virus & malware removal, system upgrades and general support questions.
Hi, I have been stumped on this problem for a number of weeks now and am now seeking some insight. I don't have any experience with dump files and so thus I am posting here.[/quote]I think only about 11 or 12 people in the entire world are really good at working with those dump files. We are very lucky to have Joe Hobart and Ben McDonald on the forum since they seem to be among that very select group.
I've been involved with computers since the early 1980s and Microsoft sytems since the early 1990s and before seeing posts by Joe / Ben, I was convinced there were no people who could use the dump files and who could also converse with us ordinary mortals.
Last edited by Rothgar; 10th January 2005 at 00:54.
Didn't find the information you thought to find? Check out these Similar Threads
We have had the majority of the memory changed. It is now running all HP certified memory where as previously it was using some Kingston mixed with HP. HP didn't want to deal with anything other than their hardware with good reasoning.
The system will sporadically crash it seems, It could be a week or a couple of days between crashing. I also have another bug check code 0x0000008E that comes up on occasion referencing different addresses.
I looked around and the cases for the 8E bug check for Windows XP seemed mainly to be memory related, however microsoft KB says it is the ntfs.sys file on Server 2003 and have an unreleased hotfix of which we have applied. It did not fix the issue however.
The last 8E bugcheck was:
0x0000008E (0xC00000005, 0x804EE997, 0xF4632ABC, 0x00000000)
That was on the 23rd of December, before holidays.
Look forward to hearing from you.
Regards,
Jason
Last edited by Rothgar; 10th January 2005 at 01:25.
Its not that small of a group. I wish it was, i'd be posting from my yacht in the carribean The reason you dont see folks cracking dumps in end user space is that most folks with debug skills are in corperate space. Reading dumps is time consuming and takes a lot of brain effort, too much to do a lot of it for free/on your free time.
Post the dump data again, go ahead and include the other one too (i think you need to make two posts due to size). Please leave the data up, so others can find the stack later from searching the web. There isnt anything in this data that is compromising, no worries.
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\system32\drivers
Windows Server 2003 Kernel Version 3790 MP (2 procs) Free x86 compatible
Product: LanManNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_gdr.040410-1234
Kernel base = 0x804de000 PsLoadedModuleList = 0x8057b6a8
Debug session time: Sun Jan 09 20:06:44 2005
System Uptime: 16 days 8:17:16.968
Loading Kernel Symbols
........................................................................... ..........................................
Loading unloaded module list
..
Loading User Symbols
*************************************************************************** ****
* *
* Bugcheck Analysis *
* *
*************************************************************************** ****
Use !analyze -v to get detailed debugging information.
BugCheck A, {8, 2, 0, 804ee997}
Probably caused by : TDI.SYS ( TDI!CTEpEventHandler+2a )
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: 00000008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804ee997, address which referenced memory
Ok, buckle up...
Your PTE table is corrupt. A driver came along and wacked this peaceful, gentle PTE queue. I do not know why, only that it did. There is the smallest of chances that it was causes by hardware, but this almost always is a driver.
(for those of you following at home this is the key to knowing this is your culprit)
nt!ExRemoveHeadNBQueue+0x61
MmMapLockedPagesSpecifyCache+0x104
This isnt fun to troubleshoot, so much so, I must tell you to call support for assistance. I'd say this is one of the one that isn't solvable over the internet with a few gentle suggestions (mostly because it requires full access to the dump, and lots of back and forth).
I'll outline how to proceed, using driver verifier, special pool, and PTE tracking, but i'm not volunteering to help you do it The below is how this usually goes.. You may get it on step 2, you may get it on step 8. I've seen them stop at every point in the list. After someone looks at your full dump, verifies my cursory analysis, the fun begins.
Step 1) enable driver verifier and special pool on all 3rd party drivers, wait for crash, examine crash, hope it caught the culprit.
Step 2) Enable PTE tracking, wait for crash, hope the guarding lets you backtrack who was touching it and make a leap of faith debug.
Step 3) Cry
Step 4) repeat above for a month until you abandon hope
Step 5) randomly swap out hardware hoping to change the enviroment enough to make it stop
Step 6) Eventually you will get a crash that catches the driver or
Step 7) Detemine you have bad hardware, start replacing backplanes and CPUs
Step 8) Receive bill for step 7, cry.
Be kind to the tech you get, its going to be a journey.
I make a funny up there, but its not funny. Poorly written Kernel drivers can cause such grief on a machine. This phenomenon cannot be well guarded against without signifigant CPU and memory expense, and even with guarding, has to happen juuust right to catch it. This is just one of those thing that kernel developers need to take more care, and do more testing, and hire smart people to develop thier drivers.
I wish you good luck in the hunt.
Last edited by BenMcDonald[MS]; 11th January 2005 at 01:04.
Reason: and heres to hoping this dump doesnt land in my inbox. hehehe
Hmm, Thanks for that Ben. Unfortunately I have no idea what a PTE table is... neither could I find any good reading information on google. I would have no idea on how that would have happened. Unless it was that dodgy program they tried to run a while ago "Public Outlook". Anyway I guess my question would be what is a PTE table, can I read anything about it? Can I replace it, perhaps with a generic one? What type of things modify the PTE table?
Microsoft I don't beleive are necessary in this problem as we plan to re-image it in around 6 months. Also we all know how much Microsoft loves to help (for the right price) and how knowledgeable most support help desk guys are. It would probably take hours to get correctly escalated.
It mentioned TDI.sys in the dump log, would that be the corrupt file? If so from what I could see on google it looked to be network related, would that mean a networking driver? Is there a way to determine what kind of driver it is from the dump, i.e what area, network, storage, display etc?
Also we all know how much Microsoft loves to help (for the right price) and how knowledgeable most support help desk guys are.
Is my check in the mail? Taking a cheap shot at the 200 folks who I eat lunch with every day who could slam dunk your dump while playing halo2 on mute?? And yet, such love have I for my customers, I still search MSN to find you links to help you improve your technical skill and help you impress your boss.
PTEs are an internal system object used to manage virtual memory
This book has 100 pages on memory management, and gets as high an endorsement from me as I can give. You want to learn what a PTE table is, there you go. Its worth it just for the first three chapters. buy this book, seriously.
It mentioned TDI.sys in the dump log, would that be the corrupt file? Step 5) randomly swap out hardware hoping to change the enviroment enough to make it stop
I see you are skipping striaght to step 5. If i could have guessed at which driver, i would have. You can play go fish with the software and maybe change the enviroment enough to make it stop crashing, but thats the act of a desperate man. Your chances of success are exactly between 0 and 100% with an untargeted fishing expidition.
If you can handle the frequency of the crashes for 6 months, then that certainly is an option. I would take regular full system state backups. All those crashes, you are bound to corrupt something.
Also we all know how much Microsoft loves to help (for the right price) and how knowledgeable most support help desk guys are.
Is my check in the mail? Taking a cheap shot at the 200 folks who I eat lunch with every day who could slam dunk your dump while playing halo2 on mute?? And yet, such love have I for my customers, I still search MSN to find you links to help you improve your technical skill and help you impress your boss.
Yeah, I seem to take my frustrations out on most help desks these days based on the experiences I have had with Veritas and HP. Although I haven't called Microsoft's HD much, I haven't had any real problem with it thus far. I just generalize.
Quote:
PTEs are an internal system object used to manage virtual memory
This book has 100 pages on memory management, and gets as high an endorsement from me as I can give. You want to learn what a PTE table is, there you go. Its worth it just for the first three chapters. buy this book, seriously.
Thanks for that, I saw a few acronyms pop up while googling but didn't find any real solid reading. I saw "Page Table Entries", still unsure if that is correct but I will read those two links and perhaps one day buy the book, there are a few others I would like to purchase.
Quote:
It mentioned TDI.sys in the dump log, would that be the corrupt file?
Step 5) randomly swap out hardware hoping to change the enviroment enough to make it stop
I see you are skipping striaght to step 5. If i could have guessed at which driver, i would have. You can play go fish with the software and maybe change the enviroment enough to make it stop crashing, but thats the act of a desperate man. Your chances of success are exactly between 0 and 100% with an untargeted fishing expidition.
I did no such thing, well at least not on purpose. I saw TDI.sys in the dump file and googled around beforehand and any reference I saw seemed to point at network. You mentioned a driver corrupted the PTE table, so I was curious as to if it could have been network drivers... I was in no way planning on changing any hardware on the system. I do believe it is software or perhaps memory issues. However it is looking more and more software related.
Quote:
If you can handle the frequency of the crashes for 6 months, then that certainly is an option. I would take regular full system state backups. All those crashes, you are bound to corrupt something.
Yeah we have been dealing with them for a while now and have been doing full backups every night with a 2 week rotation. This includes the system state and once a week a tape is taken off site. We feel the same way, eventually we foresee it not coming back up after one of these crashes. It already corrupted the registry once. However they have deadlines and don't want us to touch the server.
I'll read those two links and let you know if I have any more questions.
Microsoft (R) Windows Debugger Version 6.3.0017.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS\system32\drivers
Windows Server 2003 Kernel Version 3790 MP (2 procs) Free x86 compatible
Product: LanManNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_gdr.040410-1234
Kernel base = 0x804de000 PsLoadedModuleList = 0x8057b6a8
Debug session time: Thu Jan 13 11:34:54 2005
System Uptime: 3 days 2:11:33.995
Loading Kernel Symbols
........................................................................... ..........................................
Loading unloaded module list
.......
Loading User Symbols
*************************************************************************** ****
* *
* Bugcheck Analysis *
* *
*************************************************************************** ****
Use !analyze -v to get detailed debugging information.
BugCheck A, {8, 2, 0, 804ee997}
*** ERROR: Symbol file could not be found. Defaulted to export symbols for TmPreFlt.sys -
Probably caused by : CLASSPNP.SYS ( CLASSPNP!SubmitTransferPacket+86 )
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: 00000008, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804ee997, address which referenced memory
![BenMcDonald[MS]'s Avatar](http://www.WindowsBBS.com/avatars/benmcdonald-ms-.gif?dateline=1103157319)
The reason you dont see folks cracking dumps in end user space is that most folks with debug skills are in corperate space. Reading dumps is time consuming and takes a lot of brain effort, too much to do a lot of it for free/on your free time. 
The below is how this usually goes.. You may get it on step 2, you may get it on step 8. I've seen them stop at every point in the list. After someone looks at your full dump, verifies my cursory analysis, the fun begins.
Taking a cheap shot at the 200 folks who I eat lunch with every day who could slam dunk your dump while playing halo2 on mute?? And yet, such love have I for my customers, I still search MSN to find you links to help you improve your technical skill and help you impress your boss.