Yes, this is what is bugging me. I was very proud to get W7 up and running stable on this old girl (and they said it could not be done!) and it ran without a problem for a long time. So now I did something and screwed it up. I pushed it one step over the line!
I will experiment with it and let you know what I find.
Hi Archie
Got a new bluescreen last night. This one was REFERENCE_BY_POINTER, Stop 0x00000018. This one came while it was recording TV.
I'd just like to know if it is the same driver.
I have not had time to try the tests we talked about. Probably this weekend for that.
New Grabs below. Thanks man.
Mate, it is stop 0x18, as you said.
But, it is also showing nothing.Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 18, {852478e0, 85466d48, 1, fffffffe} Probably caused by : ntkrnlmp.exe ( nt!ObfDereferenceObjectWithTag+4b ) Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* REFERENCE_BY_POINTER (18) Arguments: Arg1: 852478e0, Object type of the object whose reference count is being lowered Arg2: 85466d48, Object whose reference count is being lowered Arg3: 00000001, Reserved Arg4: fffffffe, Reserved The reference count of an object is illegal for the current state of the object. Each time a driver uses a pointer to an object the driver calls a kernel routine to increment the reference count of the object. When the driver is done with the pointer the driver calls another kernel routine to decrement the reference count. Drivers must match calls to the increment and decrement routines. This bugcheck can occur because an object's reference count goes to zero while there are still open handles to the object, in which case the fourth parameter indicates the number of opened handles. It may also occur when the object’s reference count drops below zero whether or not there are open handles to the object, and in that case the fourth parameter contains the actual value of the pointer references count. Debugging Details: ------------------ CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0x18 PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 82c6045c to 82cdc490 STACK_TEXT: 8e86dcc4 82c6045c 00000018 852478e0 85466d48 nt!KeBugCheckEx+0x1e 8e86dce8 82c6040a 85466d48 82c78f5e 82d43360 nt!ObfDereferenceObjectWithTag+0x4b 8e86dcf0 82c78f5e 82d43360 852b9a70 82d3cbb8 nt!ObfDereferenceObject+0xd 8e86dcf4 82d43360 852b9a70 82d3cbb8 82c65173 nt!PspReaper+0x84 8e86dd50 82df250a 00000002 c0b470e6 00000000 nt!PsReaperWorkItem 8e86dd90 82c93879 82c65066 00000002 00000000 nt!PspSystemThreadStartup+0x9e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19 STACK_COMMAND: kb FOLLOWUP_IP: nt!ObfDereferenceObjectWithTag+4b 82c6045c cc int 3 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!ObfDereferenceObjectWithTag+4b FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 503f7f30 FAILURE_BUCKET_ID: 0x18_CORRUPT_REF_COUNT_nt!ObfDereferenceObjectWithTag+4b BUCKET_ID: 0x18_CORRUPT_REF_COUNT_nt!ObfDereferenceObjectWithTag+4b Followup: MachineOwner --------- 0: kd> !object 85466d48 GetUlongFromAddress: unable to read from 82d69824 Could not read ObjectType address
From Carrona.org, STOP 0x00000018: REFERENCE_BY_POINTER
Usual causes: Device driver, kernel, hardware
About hardware, we have the knowledge that it is old. But, we need to check for the drivers once again, as nothing is stressed in the dump.
Well, in the weekend then :)
I've just disabled the Soundmax Device. We will see if that makes any difference between now and then.
Thanks again!
You were right on about the sound drivers Archie. They are none-the-good.
However, the system crashed once again with the sound device disabled.
Stop 0x8E. This one occurred going into sleep mode.
I ran a bunch of tests this morning with Driver Verifier. This is what I found:
- All non-Microsoft drivers (that are not sound related) work (no crashes when I check these individually)
- Sound drivers definitely crash. portcls.sys and smwdm.sys. (dmk.sys is OK.)
- Selecting only Microsoft drivers, but not any sound drivers or non-MS drivers, also crashed. Stop 0xC4.
The last dump file is the one where the crash occurred with just MS drivers - no sound.
Do you see anything different in that dump?
TIA
You are a real geek, TVeblenYou used DV beautifully.
There are five crash dumps in the zip, and all are stop 0xC4, DRIVER_VERIFIER_DETECTED_VIOLATION.
And, all of them are caused by SoundMAX Integrated Digital Audio driver (smwdm.sys) and Andrea Electronics Corp Audio Noise Cancellation Driver (aeaudio.sys). All are almost the same.
It is from the last one, 04/11/2012; 11:40 AM.Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck C4, {f6, 1cc, b6e56d40, 836025e5} *** WARNING: Unable to verify timestamp for smwdm.sys *** ERROR: Module load completed but symbols could not be loaded for smwdm.sys *** WARNING: Unable to verify timestamp for aeaudio.sys *** ERROR: Module load completed but symbols could not be loaded for aeaudio.sys Probably caused by : smwdm.sys ( smwdm+2d1fb ) Followup: MachineOwner ---------
But unfortunately I haven't found a crash dump with the Stop 0x8E. It is very difficult to infer about it without seeing the dump, coz it covers a wide area.
STOP 0x0000008E: KERNEL_MODE_EXCEPTION_NOT_HANDLED
Usual causes: Insufficient disk space, Device driver, Video card, BIOS, Breakpoint in startup without having a debugger attached, Hardware incompatibility, Faulty system service, 3rd party remote control, Memory.
Can you not make it sure about one, without seeing the crash dump
So.... what to do next ? :)
Ach! Such a dummy! I ran CCleaner to get some nice clean dump reports and deleted the dump with the 0x8E. Excuse me while I give my self a good dope-slap.
There, that's better!
I can't thank you enough Archie. I feel it is pretty obvious what is going on with this old Betsy. I'll play with some more drivers and keep my eye on it. Maybe even find a PCI sound card, with at least Vista drivers, on EBay! I won't waste any more of your time with the obvious. I know you guys are busy over here!
TVeblen, how much I may be busy, you are always welcome, and your issue is the priority.
If your computer is not running at its best, a lot of OPs will suffer there
Oh! MY computer (the one in my specs) runs smooth as silk!
This old Pentium 4 machine has been downgraded to the PVR station. Not that recording TV programs is a minor job.
Here's how it works:
- I build a sate-of-the-art new machine for myself (goes my office)
- The PC that was in my office gets demoted to Family PC
- The Family PC gets demoted to PVR PC
- The PVR PC gets sold off for parts.
And it's looking real obvious that I will be building a new machine this winter!
Quote
