Dump file question.....

Load the dump file in WinDbg (free from Microsoft)

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Let me state again, I am looking for someone that knows how to fully INTERPRATE the dump file, not just load it and run an "!Analyze -v" to find out what the cause is. I have learned a little in reading them in Windbg, but need further assistance in the advanced commands....

Cusrious to see if someone here that is familiar with reading them in depth might know of some commands to help read the call stack further than I can.....

Upload the minidump and post the url link here.

here ya go cpc2004....

https://filedb.experts-exchange.com/incoming/ee-stuff/3078-dumps.zip 

Like I said, I know what caused the problem, and I am thinking it has to do with the Core Duo processors, but any insight you haev will be greatly appreciated.

I have actually learned alot of debugging tips from you around various other websites......

Mini032907-01.dmp BugCheck 1000000A, {525f3f3b, ff, 1, 80540f9f}
Owning Process            87b9eda0       Image:         Cpqdmi.exe
Mini032907-01.dmp Probably caused by : ntkrpamp.exe ( nt!Kei386EoiHelper+103 )

Mini032907-02.dmp BugCheck 1000000A, {fffffffc, ff, 1, 80540f9f}
Owning Process            87c005f0       Image:         Cpqdmi.exe
Mini032907-02.dmp Probably caused by : ntkrpamp.exe ( nt!Kei386EoiHelper+103 )


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: 525f3f3b, memory referenced
Arg2: 000000ff, IRQL <--- invalid IRQL (faulty memory or one device driver is installed improperly)
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80540f9f, address which referenced memory

Debugging Details:
------------------
WRITE_ADDRESS:  525f3f3b
CURRENT_IRQL:  ff

FAULTING_IP:
nt!Kei386EoiHelper+103
80540f9f 897308           mov     [ebx+0x8],esi

CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  DRIVER_FAULT
BUGCHECK_STR:  0xA
UNALIGNED_STACK_POINTER:  9645ef16
LAST_CONTROL_TRANSFER:  from 00404236 to 80540f9f

STACK_TEXT:  
9645ef16 00404236 badb0d00 9645ef16 00010003 nt!Kei386EoiHelper+0x103

Kei386EoiHelper is windows recovery routine. Recovery cannot crash. If it crashes,windows will reboot to avoid recursive recovery.  Crash at windows recovery is the symptom of hardware error. The hardware error maybe RAM, L2 cache memory of CPU, M/B or faulty PSU.  There has no reliable tools to diagnostic L2 cache memory. 80% of the memory error are related to faulty. 15% memory error is related to CPU and M/B. From your minidump, there has sufficient information to confirm it is CPU problem. The IRQL x'ff' is invalid and this is the symptom of faulty memory or one device driver is installed improperly or damaged.

The following dump is caused by double fault. The first fault is memory error. Windows recovery takes over and it crashes with stack overflow. Extend the size of stack and your version of Norton AV has known problem which causes blue screen. You had better upgrade Norton AV.
Mini033007-01.dmp BugCheck 1000007F, {8, f786bd70, 0, 0}
Owning Process            845cada0       Image:         Cpqdmi.exe
Mini033007-01.dmp Probably caused by : ntkrpamp.exe ( nt!_SEH_prolog+1a )

Mini033007-011.dmp BugCheck 1000007F, {8, f786bd70, 0, 0}
Owning Process            845cada0       Image:         Cpqdmi.exe
Mini033007-011.dmp Probably caused by : ntkrpamp.exe ( nt!_SEH_prolog+1a )  <-- stack overflow

STACK_TEXT:  
a8287372 80501c03 a82877aa 00000000 a8287726 nt!_SEH_prolog+0x1a
a82876f6 80543ed7 a82877aa a82877fa 00000000 nt!KiRaiseException+0x175
a8287712 8054060c a82877aa a82877fa 00000001 nt!NtRaiseException+0x33
a8287712 806127b8 a82877aa a82877fa 00000001 nt!KiFastCallEntry+0xfc
a8287ad6 806141ef a8287ec2 a8287ea6 804fe3aa nt!ExRaiseAccessViolation+0xa
a8287ae2 804fe3aa e610e544 000002cc 00000004 nt!ProbeForWrite+0x4d
a8287ea6 80541075 a8287ec2 00000000 a8287f16 nt!KiDispatchException+0x254
a8287f0e 80541026 4e8dfffe 80540fe1 badb0d00 nt!CommonDispatchException+0x4d
a8287f16 80540fe1 badb0d00 5de58b5b cc0004c2 nt!Kei386EoiHelper+0x18a
a8287f1a badb0d00 5de58b5b cc0004c2 cccccccc nt!Kei386EoiHelper+0x145
Procedure to extend the size of stack
http://service1.symantec.com/SUPPORT/ent-security.nsf/0/10eaa5fc1148e6f888256bf40056e227?OpenDocument

I know the RAM is fine.....L2, MOBO and PSU are all also fine, as this has happened on multiple machines. We use the HP insight software on all of our systems +1500 plus, but it seems to only happen on the Intel Core Duo's. cpqdmi actually only hangs the cpu @ 50% on the desktops, the laptops crash.....

What commands can you run in Windbg that will show the current stack size? Also, how did you come to the conclusion that it was a stack overflow?

Also, in reference to extanding the size of the stack....Are you talking about increasing the kernel stack as a whole, or just the minimum free for SAV to request the File IO?

Also, If the double fault occured due to a stack overflow, why would the dumps consistently show cpqdmi.exe?

Sorry for all the questions, I am still at an intermediate Windbg user, and am trying to understand this in full....

"Also, If the double fault occured due to a stack overflow, why would the dumps consistently show cpqdmi.exe?"

Should have read

Also, If the double fault occured due to a stack overflow CAUSED BY SYMANTEC, why would the dumps consistently show cpqdmi.exe?

Yea, we have already removed it and ALL of the crashes have stopped. No data out there on the service though via google.

I would really like to know where you saw in the stack trace that there was a stack overflow though. I am trying to learn more about the dumps, and if there are some commands or data to look at to seee the MAX stack size, I would appreciate the knowledge....

1: kd> !thread
GetPointerFromAddress: unable to read from 80561114
THREAD 86767020  Cid 0978.0990  Teb: 7ffda000 Win32Thread: e3bfa2a8 RUNNING on processor 1
IRP List:
    Unable to read nt!_IRP @ 85d4df68
Not impersonating
GetUlongFromAddress: unable to read from 80561124
Owning Process            845cada0       Image:         Cpqdmi.exe
ffdf0000: Unable to get shared data
Wait Start TickCount      372062      
Context Switch Count      3918                 LargeStack
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.0000
KernelTime                00:00:00.0000
Start Address 0x7c810659
Win32 Start Address 0x77c3a341
Stack Init a828b000 Current a828aac4 Base a828b000 Limit a8287000 <---  This is the stack limit
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 16

1: kd> r
eax=00000390 ebx=a82877aa ecx=0001001c edx=a8287726 esi=a82877aa edi=00000000
eip=8053ab8a esp=a8286fd2 ebp=a8287372 iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286
nt!_SEH_prolog+0x1a:
8053ab8a 53               push    ebx  <--- psuh instruction is crashed because stack overflow

esp=a8286fd2  <-- Note the value of esp is beyond the stack limit a8287000

Ok. Thats good enough for me. So the stack value, it is BITS, Bytes, or KB? And this is the Kernel stack size that we are talking about?

Stack Init a828b000 Current a828aac4 Base a828b000 Limit a8287000 <---  This is the ending address of the stack

Ok, I see that.....

Could you clarify my Q though, 2 posts up?

Ill close this out to you in the morning.....Learned alot more about the dmps, always good to have.....

cpc2004, closing this Q now (sorry, fell off my radar....)

Would you mind answering this little tidbit, that I never heard a response on?

"Ok. Thats good enough for me. So the stack value, it is BITS, Bytes, or KB? And this is the Kernel stack size that we are talking about? "