crash at 1:30am almost every night

[johnsonx42]

No crash yet. The 1:30am time slot last night only had one recording (South Park) so it didn't crash. It seems to require both South Park and Zula Patrol to record at the same time before it crashes. I don't think that will happen again until Tuesday morning.

[johnsonx42]

the crash happened just a bit ago at 1:30am (yes, I'm up late). It happened last night too.

These two most recent crashes were a little bit different than some occurances in that the Zula Patrol recording ends after just a few seconds, but the South Park recording went on for almost 11 minutes before ending. Last night's the South Park recording went on til 3:00am when someone (not me) had insomnia, wanted to watch a little TV and rebooted the box. I think it's happened this way before, but it's been more common that both recordings end after just a few seconds.

edit: it occurs to me that the difference may be that the c:\temp is there so that nrecord is creating the crash.mdmp. I think the South Park recording ended tonight at the same time that I acknowledged the pop-up from NRecord saying that it had created the crash.mdmp file. NRecord also seems to have terminated cleanly now; normally I find NRecord.exe stuck and un-killable, but after I acknowledged the pop-up, NRecord is gone from the task manager. I was able to re-start NRecord normally without rebooting, something that has NEVER been possible. It seems that allowing it to create the crash.mdmp makes it behave a little better.

crash.mdmp and nrecord.log attached. edit: I added the log for re-starting nrecord after the crash

[sub]

I think I can see the problem. Give these patches a go. Hopefully it'll fix the issue (which related to parsing ATSC EPG entries)

[johnsonx42]

thanks sub, I'll put them in before tonight's recordings begin. fingers crossed!

[johnsonx42]

Crashed again tonight. the crash.mdmp was written at 1:30am. the Zula Patrol recording is zero bytes, while the South Park recording ran on until I acknowledged the crash.mdmp message from NRecord (woke up around 2:30am to take a whiz, couldn't resist checking the TV). the log shows that some part of NRecord lived long enough to try to stop the South Park recording at 2:00am, but it was already crashed so it didn't stop.

I am running the npvrtsmon and npvrtsreader from the patch you posted above. I have not installed the newer npvrtsreader from the colossus thread.

Here's the entry from the Application Event Log (just one this time):

Code:

Log Name:      Application
Source:        Application Error
Date:          7/21/2011 2:42:32 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      gbpvr
Description:
Faulting application name: NRecord.exe, version: 1.0.0.0, time stamp: 0x4e1a9269
Faulting module name: NPVRTSMon.ax, version: 0.0.0.0, time stamp: 0x4e271bbc
Exception code: 0xc0000005
Fault offset: 0x0000c900
Faulting process id: 0x28c
Faulting application start time: 0x01cc4738e68e0a99
Faulting application path: C:\Program Files\NPVR\NRecord.exe
Faulting module path: C:\Program Files\NPVR\NPVRTSMon.ax
Report Id: c1624584-b37d-11e0-aef5-0015583f2cdc
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2011-07-21T09:42:32.000000000Z" />
    <EventRecordID>10289</EventRecordID>
    <Channel>Application</Channel>
    <Computer>gbpvr</Computer>
    <Security />
  </System>
  <EventData>
    <Data>NRecord.exe</Data>
    <Data>1.0.0.0</Data>
    <Data>4e1a9269</Data>
    <Data>NPVRTSMon.ax</Data>
    <Data>0.0.0.0</Data>
    <Data>4e271bbc</Data>
    <Data>c0000005</Data>
    <Data>0000c900</Data>
    <Data>28c</Data>
    <Data>01cc4738e68e0a99</Data>
    <Data>C:\Program Files\NPVR\NRecord.exe</Data>
    <Data>C:\Program Files\NPVR\NPVRTSMon.ax</Data>
    <Data>c1624584-b37d-11e0-aef5-0015583f2cdc</Data>
  </EventData>
</Event>

[sub]

That dump shows the crash not being in the same spot as last time, but in the same general area relating to parsing ATSC EIT entires. Unfortunately its very hard to tell what is actually happening with seeing the data, and be able to step through it.

I've added some more defensive checks around certain things in this patch (checking buffer sizes etc). Hopefully it'll help.

[johnsonx42]

Thanks sub. I've put the patch in, so we'll see what happens.

I did notice that last night's Zula Patrol recording was 0 bytes, while the previous night was about 7 seconds long. The night before that it was 0 again, but I didn't retrieve the crash dump for that one.

I suppose if you're not able to fix this with just crash dumps, I can try a FullTS recording of the problem frequency from 1:29:30 to 1:30:30. It's a pain to get it uploaded though, so let's see what happens...

[sub]

I suppose if you're not able to fix this with just crash dumps, I can try a FullTS recording of the problem frequency from 1:29:30 to 1:30:30.

Yep, that would be a good next step.

[johnsonx42]

No crash last night; it recorded South Park and Zula Patrol at 1:30 without incident. We can't take that as definitive though, since it does sometimes get through the night without crashing. Zula Patrol isn't on at 1:30am again until Monday night, but I'll go ahead and tell it to record whatever is on that channel at 1:30am tonight and see what happens.

edit: actually I guess Zula Patrol is on at 1:30am tonight. it wasn't last week.

[johnsonx42]

no crash again tonight. maybe those defensive checks did the trick. for the next two nights nothing is scheduled to record at 1:30am, so I'll just schedule it to record whatever's on those two channels at that time. if it gets through the weekend and the first couple of days next week, I think we can call this bug squashed at long last. I think some form of this crash has been plaguing me all the way back to GB-PVR.