BleepingComputer.com: Event Logger.

Hi i have a problem with nero, sometimes when i wanna burn a cd the pc suddenly reboots rendering the cd useless (and me pissed off ;) ) while i have "reboot on system error" turned off. Does anyone know an event logger of some type wich i could use to find what exactly is causing the problems. so i can go ahead and solve them.

The weird thing is that it seems random wich files trigger the problem, but consequent in repeating to trigger the problem with those files it does happen with. example: i have 4 different files in the same format. 1,2 and 3 burn without a problem but file 4 triggers the problem, and when repeating to try to burn file 4 the problem is triggered each time. Also while it keeps happening, it keeps happening at different points during the process. First time at for example 40% 2nd at 1% 3rd at 30%.

(yeah i know that last part doesnt really have anything to do with finding the logger but someone might already know the prob.)

If your OS is XP there is already a "logger" in the software. Take a look at: How to view and manage event logs in Event Viewer in Windows XP. See if that helps you get started. If you need more information please post back.

Be (Fiddle while it burns) Safe

Da Bleepin AniMod, Animal

i found that one to be insufficient. did find that a dcom error was present around the time of the error once but nothing else. (and after searching the string found that it had something to do with multiple simultaneous instances of msmsgr.exe)

Here's a brief way to look for BSOD info in the Event Viewer: http://www.bleepingcomputer.com/forums/topic40108.html

First tho' - this may or may not be a BSOD event. If it's an error outside of what Windows recognizes - then you won't get an error event being logged. Also, if you have the Event Logging service disabled you won't get an event. Also, if you've done things to your pagefile some of this may not apply.

BSOD's manifest themselves in 3 or 4 ways:

1) Through the BSOD screen
2) Through an entry in the Event Viewer
3) Through the creation of a memory dump (usually in C:\Windows\minidump - don't have it on my system since I monkeyed with my pagefile) These files will generally end in .dmp.
4) Through the creation of a memory dump report for Microsoft (usually in the temp files). You have to retrieve this one before sending the error report (or dismissing it). Check the Details link for the report and find the file that ends in .mdmp - then save it to another location.

If you can find .dmp or .mdmp files, you can use this link to learn how to run an anlysis - and then can post the results here for someone to look at: http://forums.majorgeeks.com/showthread.php?t=35246

Ensure that you check all of the categories (the one's listed in the left hand pane) for errors - even the most innocuous seeming one's may be the cause.

all i get is this, it seems it cant load the right symbol files.

Microsoft ® Windows Debugger Version 6.6.0007.5
Copyright © Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Documents and Settings\Rick\Bureaublad\minidumps\Mini071805-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Mon Jul 18 19:16:54.062 2005 (GMT+1)
System Uptime: 0 days 10:12:19.626
Loading Kernel Symbols
...............................................................................................................................
Loading User Symbols
Loading unloaded module list
......................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 100000EA, {81b88300, 81b93b20, f895dcb4, 1}

*** WARNING: Unable to verify timestamp for nv4_mini.sys
*** ERROR: Module load completed but symbols could not be loaded for nv4_mini.sys
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: watchdog!_DEFERRED_WATCHDOG ***
*** ***
*************************************************************************
Probably caused by : nv4_mini.sys ( nv4_mini+4a7a4 )

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

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

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 81b88300, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 81b93b20, Pointer to a DEFERRED_WATCHDOG object.
Arg3: f895dcb4, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

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

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: watchdog!_DEFERRED_WATCHDOG ***
*** ***
*************************************************************************

FAULTING_THREAD: 81b88300

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from 804e39ce to 804db7f3

STACK_TEXT:
b9f08218 804e39ce f895db40 f895db70 00000000 nt!KiUnlockDispatcherDatabase+0x77
b9f0822c f88e6a67 f895db94 00000000 00000000 nt!KeSetEvent+0x74
b9f08520 804f0282 f895db40 b9f0856c b9f08560 watchdog!WatchdogKernelApc+0x13b
b9f08570 806efc35 00000000 00000000 b9f08588 nt!KiDeliverApc+0xb3
b9f08570 804d90ac 00000000 00000000 b9f08588 hal!HalpApcInterrupt+0xc5
b9f085f8 f7fff7a4 f6a71400 81fec448 f801df2f nt!READ_REGISTER_ULONG+0x6
WARNING: Stack unwind information not available. Following frames may be wrong.
b9f08600 81fec448 f801df2f 81fecc20 81fec448 nv4_mini+0x4a7a4
b9f08604 f801df2f 81fecc20 81fec448 00009400 0x81fec448
b9f08608 81fecc20 81fec448 00009400 81fec448 nv4_mini+0x68f2f
b9f0860c 81fec448 00009400 81fec448 81fe5008 0x81fecc20
b9f08610 00000000 81fec448 81fe5008 81fecc20 0x81fec448


STACK_COMMAND: .thread 0xffffffff81b88300 ; kb

FOLLOWUP_IP:
nv4_mini+4a7a4
f7fff7a4 ?? ???

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: nv4_mini+4a7a4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nv4_mini

IMAGE_NAME: nv4_mini.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 42b0d148

FAILURE_BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_2005_06_16

BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_2005_06_16

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

by the way this was the dcom error found around the time of the error with nero:
type of event: error
Source of event: DCOM
Categorie of event: none
Event-ID: 10010
Description:
The server {F3A614DC-ABE0-11D2-A441-00C04F795683} did not register with dcom within the specified time-out.

The DCOM error appears to be a time out error - not much of a concern as long as it doesn't recur on a regular basis.

But the analysis points at your nVidia video card drivers as the culprit (the nv4_mini.sys file).

So, I'd suggest uninstalling your current video drivers and then reinstalling the latest ones available here: http://www.nvidia.com/content/drivers/drivers.asp

This may or may not cure the problem - but it's the first step in fixing it. Once the nVidia drivers are updated, any further problems will help to point us even closer to the culprit program.

Since this problem occurs frequently in Nero - I'd expect it to be a part of the problem. So, an uninstall and reinstall of Nero with all the updates might be called for.

at the moment my parents kicked me out, so i cant go and try changing the drivers right now. but have thrown out nero 6 and installed nero 7 instead, and guess what.... same thing. burning begins, burns a little, sudden reboot. the most weird thing about this all is that it doesnt happen with a specific video format or something like that, ive checked that with a few different movies with the same encoder and format. just totally random wich ones it happens with.

Here's a free burner that doesn't require any installation - give it a try to see if it works (when you can). If it does, then it's likely the problem is with the other burning software. http://www.silentnight2004.com/microburner.html

thnx tried and it worked fine, ill just be using that one for now till i get a better one

Actually, it's my "troubleshooting" tool that I use to diagnose CD/DVD writer problems Since it's so small, I use it for most of my burning needs (I don't do music or videos).