(In)Consistent system crash on Win 7

Archive of historical bug reports.
Please use the GitHub link above to report issues.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
mkelley
Bright Spark User
Posts: 389
Joined: Fri Dec 25, 2009 2:00 am

(In)Consistent system crash on Win 7

Post by mkelley »

Handbrake has been bringing my entire system down repeatedly over the last month or so since I've been using the builds allowing blu-ray detection. I've been upgrading to the latest but they don't seem to solve this problem. Things I know (and don't know):

1) It's Handbrake. Without Handbrake running my system (i7, Win7) is stable and runs continuously 24/7 (for weeks at a time), no matter what else I am doing. When I start a Handbrake encode things start to go south even though it's the only application running.

2) I get a system reboot and/or blue screen crash. Sometimes, when I am on the machine (on those few occasions I am trying to do something else at the same time, like browsing the web) I get a "not enough resources" error that locks things up and causes me to have to reboot manually. But without anything else running Handbrake usually just brings the whole system down.

3) It sometimes happens when there are items on the queue and it is finished with the last item and is just starting the next. But it also can happen in the middle of an encode (so the inconsistent part). And it can finish a file it crashed on earlier, or sometimes it will crash on a file it finished fine earlier. Either way, the outcome is the same.

4) These files encode fine on my Macbook Air, running the Mac nightlies (which is what I am doing in the meantime, since I've given up on the Win nightlies).

I'm including the last encode log where it ended before the encode finished (crashed). I have lots of other logs but I'm guessing they aren't going to be of much help (and most likely, this post will have to be put aside -- as a former programmer I well understand the inability to debug an unreproducable issue, even though *I* can reproduce it every single time, somehow :>)

Code: Select all

HandBrake svn5026 2012102301
OS: Microsoft Windows NT 6.1.7601 Service Pack 1
CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
Ram: 12278 MB, Screen: 1680x1050
Temp Dir: C:\Users\Michael\AppData\Local\Temp\
Install Dir: C:\Program Files (x86)\Handbrake
Data Dir: C:\Users\Michael\AppData\Roaming\HandBrake\HandBrake\0.9.8.5024

-------------------------------------------

CLI Query:  -i "V:\00_DVDs\CE3K" -t 1 --angle 1 -c 1-20 -o "V:\Ce3k-1.mkv"  -f mkv  -w 1920 --loose-anamorphic  --modulus 16 -e x264 -q 20 --cfr -a 7 -E copy:dtshd -6 auto -R Auto -B 0 -D 0 --gain 0 --audio-copy-mask none --audio-fallback ffac3 --markers="C:\Users\Michael\AppData\Local\Temp\Ce3k-1-1-chapters.csv" -x b-adapt=2:rc-lookahead=50 --verbose=1
User Query: False

[08:32:07] hb_init: starting libhb thread
HandBrake svn5026 (2012102301) - MinGW i686 - http://handbrake.fr
8 CPUs detected
Opening V:\00_DVDs\CE3K...
[08:32:07] hb_scan: path=V:\00_DVDs\CE3K, title_index=1
[08:32:07] scan: BD has 30 title(s)
[08:32:07] bd: scanning title 1
[08:32:07] bd: playlist 00054.MPLS
[08:32:07] bd: duration is 02:14:44 (8084617 ms)
[08:32:07] bd: video id=0x1011, stream type=H.264, format 1080p
[08:32:07] bd: aspect = 1.77778
[08:32:07] bd: audio id=0x1100, lang=Espanol (AC3), 3cc=spa
[08:32:07] bd: audio id=0x761101, lang=English (AC3), 3cc=eng
[08:32:07] bd: audio id=0x721101, lang=English (TrueHD), 3cc=eng
[08:32:07] bd: audio id=0x761102, lang=Francais (AC3), 3cc=fra
[08:32:07] bd: audio id=0x721102, lang=Francais (TrueHD), 3cc=fra
[08:32:07] bd: audio id=0x711103, lang=English (DTS), 3cc=eng
[08:32:07] bd: audio id=0x1103, lang=English (DTS-HD MA), 3cc=eng
[08:32:07] bd: subtitle id=0x1200, lang=English, 3cc=eng
[08:32:07] bd: subtitle id=0x1201, lang=English, 3cc=eng
[08:32:07] bd: subtitle id=0x1202, lang=Francais, 3cc=fra
[08:32:07] bd: subtitle id=0x1203, lang=Espanol, 3cc=spa
[08:32:07] bd: subtitle id=0x1204, lang=Arabic, 3cc=ara
[08:32:07] bd: subtitle id=0x1205, lang=Chinese, 3cc=zho
[08:32:07] bd: subtitle id=0x1206, lang=Korean, 3cc=kor
[08:32:07] bd: subtitle id=0x1207, lang=Portugues, 3cc=por
[08:32:07] bd: subtitle id=0x1208, lang=Thai, 3cc=tha
[08:32:07] bd: chap 1 packet=768, 664413 ms
[08:32:07] bd: chap 2 packet=3115462272, 217008 ms
[08:32:07] bd: chap 3 packet=4066621248, 280488 ms
[08:32:07] bd: chap 4 packet=5329368384, 243493 ms
[08:32:07] bd: chap 5 packet=6427343232, 959792 ms
[08:32:07] bd: chap 6 packet=10742457792, 433850 ms
[08:32:07] bd: chap 7 packet=12687331584, 759467 ms
[08:32:07] bd: chap 8 packet=16156152576, 975307 ms
[08:32:07] bd: chap 9 packet=20439036288, 226100 ms
[08:32:07] bd: chap 10 packet=21463510272, 262845 ms
[08:32:07] bd: chap 11 packet=22683336384, 465047 ms
[08:32:07] bd: chap 12 packet=24759857472, 515640 ms
[08:32:07] bd: chap 13 packet=27300139776, 186561 ms
[08:32:07] bd: chap 14 packet=28068488640, 185894 ms
[08:32:07] bd: chap 15 packet=28921356288, 295128 ms
[08:32:07] bd: chap 16 packet=30117979392, 246329 ms
[08:32:07] bd: chap 17 packet=31148307072, 250792 ms
[08:32:07] bd: chap 18 packet=32235710592, 232065 ms
[08:32:07] bd: chap 19 packet=33314737920, 342300 ms
[08:32:07] bd: chap 20 packet=34982707968, 342091 ms
[08:32:07] bd: title 1 has 20 chapters
[08:32:07] scan: decoding previews for title 1
[08:32:07] scan: title angle(s) 1
[08:32:07] scan: audio 0x711103: dca, rate=48000Hz, bitrate=1536000 English (DTS) (5.1 ch)
[08:32:07] scan: audio 0x1103: dca, rate=48000Hz, bitrate=1536000 English (DTS-HD MA) (5.1 ch)
[08:32:07] scan: audio 0x1100: AC-3, rate=48000Hz, bitrate=448000 Espanol (AC3) (5.1 ch)
[08:32:07] scan: audio 0x761101: AC-3, rate=48000Hz, bitrate=448000 English (AC3) (5.1 ch)
[08:32:07] scan: audio 0x761102: AC-3, rate=48000Hz, bitrate=448000 Francais (AC3) (5.1 ch)
[08:32:07] scan: audio 0x721101: truehd, rate=48000Hz, bitrate=200000 English (TrueHD) (5.1 ch)
[08:32:07] scan: audio 0x721102: truehd, rate=48000Hz, bitrate=200000 Francais (TrueHD) (5.1 ch)
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
Scanning title 1...
[08:32:08] scan: 10 previews, 1920x1080, 23.976 fps, autocrop = 132/132/0/0, aspect 16:9, PAR 1:1
[08:32:08] stream: 5 good frames, 0 errors (0%)
[08:32:08] scan: title (0) job->width:1920, job->height:816
[08:32:08] libhb: scan thread found 1 valid title(s)
+ title 1:
  + playlist: 00054.MPLS
  + duration: 02:14:44
  + size: 1920x1080, pixel aspect: 1/1, display aspect: 1.78, 23.976 fps
  + autocrop: 132/132/0/0
  + chapters:
    + 1: cells 0->0, 0 blocks, duration 00:11:04
    + 2: cells 0->0, 0 blocks, duration 00:03:37
    + 3: cells 0->0, 0 blocks, duration 00:04:40
    + 4: cells 0->0, 0 blocks, duration 00:04:03
    + 5: cells 0->0, 0 blocks, duration 00:16:00
    + 6: cells 0->0, 0 blocks, duration 00:07:14
    + 7: cells 0->0, 0 blocks, duration 00:12:39
    + 8: cells 0->0, 0 blocks, duration 00:16:15
    + 9: cells 0->0, 0 blocks, duration 00:03:46
    + 10: cells 0->0, 0 blocks, duration 00:04:23
    + 11: cells 0->0, 0 blocks, duration 00:07:45
    + 12: cells 0->0, 0 blocks, duration 00:08:36
    + 13: cells 0->0, 0 blocks, duration 00:03:07
    + 14: cells 0->0, 0 blocks, duration 00:03:06
    + 15: cells 0->0, 0 blocks, duration 00:04:55
    + 16: cells 0->0, 0 blocks, duration 00:04:06
    + 17: cells 0->0, 0 blocks, duration 00:04:11
    + 18: cells 0->0, 0 blocks, duration 00:03:52
    + 19: cells 0->0, 0 blocks, duration 00:05:42
    + 20: cells 0->0, 0 blocks, duration 00:05:42
  + audio tracks:
    + 1, Espanol (AC3) (5.1 ch) (iso639-2: spa), 48000Hz, 448000bps
    + 2, English (AC3) (5.1 ch) (iso639-2: eng), 48000Hz, 448000bps
    + 3, English (TrueHD) (5.1 ch) (iso639-2: eng)
    + 4, Francais (AC3) (5.1 ch) (iso639-2: fra), 48000Hz, 448000bps
    + 5, Francais (TrueHD) (5.1 ch) (iso639-2: fra)
    + 6, English (DTS) (5.1 ch) (iso639-2: eng), 48000Hz, 1536000bps
    + 7, English (DTS-HD MA) (5.1 ch) (iso639-2: eng)
  + subtitle tracks:
    + 1, English (iso639-2: eng) (Bitmap)(PGS)
    + 2, English (iso639-2: eng) (Bitmap)(PGS)
    + 3, Francais (iso639-2: fra) (Bitmap)(PGS)
    + 4, Espanol (iso639-2: spa) (Bitmap)(PGS)
    + 5, Arabic (iso639-2: ara) (Bitmap)(PGS)
    + 6, Chinese (iso639-2: zho) (Bitmap)(PGS)
    + 7, Korean (iso639-2: kor) (Bitmap)(PGS)
    + 8, Portugues (iso639-2: por) (Bitmap)(PGS)
    + 9, Thai (iso639-2: tha) (Bitmap)(PGS)
Reading chapter markers from file C:\Users\Michael\AppData\Local\Temp\Ce3k-1-1-chapters.csv
[08:32:09] 1 job(s) to process
[08:32:09] starting job
[08:32:09] sync: expecting 193836 video frames
[08:32:09] job configuration:
[08:32:09]  * source
[08:32:09]    + V:\00_DVDs\CE3K
[08:32:09]    + title 1, chapter(s) 1 to 20
[08:32:09]  * destination
[08:32:09]    + V:\Ce3k-1.mkv
[08:32:09]    + container: Matroska (.mkv)
[08:32:09]      + chapter markers
[08:32:09]  * video track
[08:32:09]    + decoder: h264
[08:32:09]      + bitrate 200 kbps
[08:32:09]    + frame rate: 23.976 fps -> constant 23.976 fps
[08:32:09]    + filters
[08:32:09]      + Framerate Shaper (1:27000000:1126125)
[08:32:09]        + frame rate: 23.976 fps -> constant 23.976 fps
[08:32:09]      + Crop and Scale (1920:816:132:132:0:0)
[08:32:09]        + source: 1920 * 1080, crop (132/132/0/0): 1920 * 816, scale: 1920 * 816
[08:32:09]    + loose anamorphic
[08:32:09]      + storage dimensions: 1920 * 816, mod 16
[08:32:09]      + pixel aspect ratio: 1 / 1
[08:32:09]      + display dimensions: 1920 * 816
[08:32:09]    + encoder: H.264 (x264)
[08:32:09]      + options: b-adapt=2:rc-lookahead=50
[08:32:09]      + quality: 20.00 (RF)
[08:32:09]  * audio track 1
[08:32:09]    + decoder: English (DTS-HD MA) (5.1 ch) (track 7, id 0x1103)
[08:32:09]      + bitrate: 1536 kbps, samplerate: 48000 Hz
[08:32:09]    + DTS-HD Passthru
[08:32:09] encx264: min-keyint: 24, keyint: 240
[08:32:09] encx264: encoding with stored aspect 1/1
[08:32:09] encx264: Encoding at constant RF 20.000000
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
[08:32:09] reader: first SCR 1044806 id 0x1011 DTS 1044806
x264 [info]: profile High, level 4.0
[08:32:09] h264: "Chapter 1" (1) at frame 0 time 3754
[08:32:09] sync: first pts is 3754
User avatar
JohnAStebbins
HandBrake Team
Posts: 5726
Joined: Sat Feb 09, 2008 7:21 pm

Re: (In)Consistent system crash on Win 7

Post by JohnAStebbins »

Try monitoring memory usage while HandBrake is running. Maybe HandBrake is consuming all available memory. That's the only thing I can think of as a possibility that isn't a hardware problem.

Note that "Without Handbrake running my system (i7, Win7) is stable and runs continuously 24/7 (for weeks at a time)" does not necessarily imply that there is no hardware problem. HandBrake works your system harder than any other application you would normally run. So I still recommend checking all the usual suspects thoroughly. That means running prime95 for a while to heat things up and memtest86 to check your memory modules.
mkelley
Bright Spark User
Posts: 389
Joined: Fri Dec 25, 2009 2:00 am

Re: (In)Consistent system crash on Win 7

Post by mkelley »

Thanks, John -- I'll give memtest86 a try.

My hardware ignorance knows no bounds. I was under the assumption that with very few exceptions (Adobe Premiere 64big being one of them) that none of the applications I have can use more than a 4gb chunk of memory they were spawned in. While I have 12GB I was kind of bummed to read this, but are you saying that Handbrake is one of those very few that can use more (or am I just mistaken, which would not surprise me any)?

Also, I went back to the nightlies thinking I would try out the 32bit version to see if there was a difference and realized that the last one I installed WAS the 32bit version rather than the 64. Now, I could have SWORN that earlier I was using the 64bit version, but now I'm not completely sure. So I went ahead and installed the 64bit version and after running all night (and completing three encodes on the queue) my system is still intact, which is better than it has done in a month. I'm beginning to think that maybe it was running the 32bit version that was causing issues -- is that a possibility? I mean, it really shouldn't matter, right?
Deleted User 11865

Re: (In)Consistent system crash on Win 7

Post by Deleted User 11865 »

Well, the 64-bit build can theoretically use more than 4 GB of RAM. But it should not use more than 2-3 GB under normal circumstances (and less for standard definition).
tlindgren
Bright Spark User
Posts: 260
Joined: Sun May 03, 2009 2:14 pm

Re: (In)Consistent system crash on Win 7

Post by tlindgren »

mkelley wrote:I'm beginning to think that maybe it was running the 32bit version that was causing issues -- is that a possibility? I mean, it really shouldn't matter, right?
It doesn't matter, the simple fact that the OS crashed means you one or more of:
  • Faulty hardware
  • Faulty drivers
  • Broken OS
It really is that simple, a normal program should not be able to ever crash a modern OS (for Windows that means NT or later, like 2000/XP/Vista/7/8). Once you fixed whatever is broken, you'll find that HandBrake won't be crashing the OS.

Now, the reason why HandBrake might crash Windows while most other programs doesn't is that it uses a lot of cpu and quite frankly very, very few other programs ever push a machine that hard. The few other programs that does push really hard is mostly test program people who overclock use to stress their machine to see if it's stable (and even when using them there's been instances where HB found issues that they missed).

The 32-bit version of HandBrake is slightly slower (IIRC 5-10%) than the 64-bit version, all other things being equal. If the encode speed is limited by decoding speed, that could potentially mean it'd push the machine slight harder. But it's unlikely that this matters, if there's a difference it's much more likely to be caused by "luck of the draw", slight difference might cause marginally different CPU heating and memory access patterns.

With regard to testing to find out what isn't working, that's always a complicated process especially when you don't have spare parts that you can just swap in.

Obviously, if any part of the machine (CPU, memory, graphics card) is overclocked that's the primary suspect, check everything with non-overclocked settings (frequency, volt) then if that works you clearly pushed too hard and need to dial back at least somewhat. Also note that components degrade over time (faster when hot as in overclocked), it's not uncommon when overclocking for things to work at first then later start to go wrong (first subtly, then worse). That's why if you do overclock you should find a stable point, then ratchet back several notches to increase the chance it stays stable.

Memory is one possibility, I'd say run memtest86+ for at least 24 hours, possibly 48+ hours as the first test.
The next suspect is CPU heat, though normally that should manifest as big slowdowns rather than crashes, run one of the temperature measuring programs while doing stressful things. But it does happen now and then.
If all that checks out it's a cornucopia of different things that could be involved, it can't really be cut down to a "do A, then B" description.
mkelley
Bright Spark User
Posts: 389
Joined: Fri Dec 25, 2009 2:00 am

Re: (In)Consistent system crash on Win 7

Post by mkelley »

Well, I do understand what you are saying... but it's interesting now that I've done four encodes since switching versions and had no crashes (when I couldn't even get through ONE encode in a month prior to this, despite trying dozens of times). Same files, same everything... except different Handbrake version.

So I'm not denying this is a hardware issue, just that it's VERY curious that (so far, at least) everything now seems to be working just fine when it clearly wasn't before. Until it crashes again (and it may, any minute now :>) I'm not going to worry about it (this is a fairly old by computer standards Dell computer, so replacement isn't out of the question, although I'd be tempted to buy a much more powerful machine just because <g>).
Post Reply