Reboot with no BSOD

General Support / Questions
1

All of a sudden I’m running into an issue with MCEBuddy. I’ll start transcoding with it just like always per my schedule and anywhere from 5minutes to 4 hours after I start my machine reboots without a BSOD, no minidump file is created. I’m doing the transcoding on the same machine as hosts my Windows 7 media center and I have 5 extenders, most of the time 2 - 3 are in use.

I have upgraded my Video card to a Geforce210 1024MB card, added a liquid cooling system to my PC and tried writing the files to both my SSD and my spinning platter drive. I’ve disabled hardware encoding, tried utilizing a different number of simultaneous transcodes and I just can’t seem to figure out the issue. I’ve made sure I have the most recent stable drivers for my video card and other components in the PC.

I’m using a Core I5760 Lynnfield processor with 16GB RAM. This issue started out of the blue about 2 weeks ago. I have windows updates turned off on the due to some issues with media center and the machine was rebuilt from scratch back in January. I have 1 Ceton PCI 4 tuner card in the PC and my other tuners are HDHOMERUN.

I recently upgraded to MCEBuddy 2.4 Beta 8 and that has not solved the issue.

2

First I’m sure you’re aware that a BSOD/reboot can only be caused by

  1. Bad device driver
  2. Faulty hardware

Regular software cannot cause a BSOD/reboot, they run in protected user mode and the most that can happens is the software crashes/is killed by Windows.

MCEBuddy does video encoding which can really stress the system out (graphics, hard disk, memory, cpu, NIC, bus etc) so if anything isn’t working perfectly it’ll cause the driver/hardware to BSOD/reboot.

The first and most common culprit is the video graphics driver and the best way to test it is by disabling hardware encoding, if that solves the problem you know it’s the graphics driver. Just a note, most recent does not mean most stable (from experience). Intel is NOTORIOUS for making bad graphics drivers which crash the system all the time.

What we’ve also seen in the past (and you get details from the old codeplex website under closed issues) are due to hard disk and memory and/or other hardware like RAM or add on cards.

The second most common reason has been the Hard Disk, usually a SSD hard disk. The best way to resolve this would be to a deep scan of your SSD/HD and see if there are any bad sectors or disk issues. If there are issues with the disk controller the only way to know would be to replace the HD/SDD or replace the HD controller/motherboard.

Also if you’re overclocking your CPU/Bus/Graphics/RAM etc it can cause issues. Detune everthing set it to the lowest/slowest setting, under clock it to see if it’s tweaking causing the issue.

Finally it would be the RAM or Bus (which is back to motherboard). RAM can be eliminating by running stress tests on it for a few hours or better yet just replace it (or remove it) and see if the problem goes away.

The hardest to debug is motherboard/bus problems. The only way here apart from running stress tests is to replace it.

If it’s no BSOD, check your windows settings and see if it’s set to auto reboot after a crash. BSOD is typically a problem of bad drivers or a kernel space crash or a hardware problem which has been caught by the kernel. There are crashes which are skipped by the kernel and can cause a total reboot without a BSOD, these are usually pretty serious hardware issues.

Hope this helps.

3

It would appear the issue is with my NIC which is odd. Once I set the file location for the transcoded file to a local drive I haven’t had the issue and I’ve been transcoding heavy for about 12 hours. System uptime is 19 hours. I will see what happens when I put a new PCI-E NIC in that I ordered, I had been using the onboard gig port (Realtek I think).

Thanks,

Brandon

1 Like