Jump to content

Multiple simultaneous read to ISO can crash one instance


Recommended Posts

Posted

I've been noticing this on and off for a while, but, since I have a work-around, I figured it was ok to ignore it.

As background: I buy quite a few disc titles every week; it's a pleasant obsession, and I do manage to watch almost all of them! I convert each disc to an unprotected ISO on NAS for backup and local playback purposes via Dune players around the house.

My workflow involves using someone else's unprotection software, then starting up to five instances of ImgBurn.  Obviously, up to 5 Blu-ray drives are involved.

I set up each instance of ImgBurn to rip to ISO, and point each one at the correct NAS folder and filename, and then start READing on all the instances, one after the other.

If I click on the READ icon of each instance in quick succession -- less than a second between clicks -- then at least half the time one of the instances crashes, usually within seconds.

If, instead, I click the READ icon on one instance, wait until it is reading sectors, and then click the READ icon on the next instance, wait until it is reading sectors, and so on, then none of the ImgBurn instances crash.

If I had to guess, the initial phase of determining read speeds, drive capabilities, disc size, parsing the UDF (?) data might cause some kind of interference between the instances that doesn't happen during the reading of sector data.

I can provide further information if you tell me what to look for, if you think this is worth investigating. 

Cheers,

--michael

Posted

It's a hard crash: Windows says the program has stopped working, do I want to terminate it or terminate and check for solutions?

There's no offer by ImgBurn to send a log. 

Posted

In that case, please try and see what's written in the log window and the status bar (of the main window) of the one that's supposedly crashed. That info will help pinpoint what it was doing at the time.

Posted

Will do. Naturally, when I threw in a bunch of Blu-rays and set a bunch of simultaneous rips running yesterday, the problem didn't show up. Then I spent more than an hour starting, stopping, restarting the rips and....nothing. A perfect example of demo syndrome! You'll be the first to know when it does happen again. It shouldn't be long...

Cheers,

--michael

  • 3 weeks later...
Posted

Finally, it happened again. Unfortunately, the Windows crash panel popped up, and I did try to get at the log window for the ImgBurn instance that crashed, but when I restored the log window it was blank and the crash panel took the focus. No matter what I did the log window was not able to refresh due to the crash.

The crash information was:

Problem signature:
  Problem Event Name:    BEX
  Application Name:    ImgBurn.exe
  Application Version:    2.5.8.0
  Application Timestamp:    00000000
  Fault Module Name:    StackHash_2264
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    00000000
  Exception Offset:    1044fc6e
  Exception Code:    c0000005
  Exception Data:    badc0de1
  OS Version:    6.1.7601.2.1.0.256.1
  Locale ID:    1033
  Additional Information 1:    2264
  Additional Information 2:    2264db07e74365624c50317d7b856ae9
  Additional Information 3:    875f
  Additional Information 4:    875fa2ef9d2bdca96466e8af55d1ae6e

 

Is there anything more I can do at this end? Is the log stored somewhere temporary when ImgBurn is running, so that I might be able to capture it? Maybe there's a command line switch that can force ImgBurn to write the log rather than storing the log in memory and writing when it exits?

Anything you want to me to do to analyze this problem I can and will do. Debugging was my speciality when I was chief programmer/bottle washer/team leader for Blackberry way back in the 1990's...

Cheers,

--michael

Posted

After a bit of Googling, it seems that sort of crash (Fault Module Name: StackHash_2264) is due to DEP.

As mentioned before, if ImgBurn itself crashes, it generates a report and offers to send it to me. You aren't getting that and are instead getting a crash within the OS.

I don't know if that sort of crash would produce a minidump or whatever, but there could be more info in the eventlog or perhaps available by a 3rd party app from the likes of sysinternals or nirsoft.

 

Posted

I found the Windows crash dump folder for ImgBurn, and have zipped it all into to 90+MB file. I'd rather not post it publicly as it likely has lots of information that shouldn't be out in the world.

I've sent a DropBox link to you, Lightning UK! At least, I hope I have!

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.