Thread: Append Checksum "Unhandled Exception" Error

Hello all, I hope I'm going about this the right way, a search has provided no answers. When using EAC 1.0b1 on my Windows XP machine (SP-3, all MS updates), I encounter the following "Unhandled Exception" error when attempting to create a log after ripping when and only when the "Append checksum to status report" option is checked:

Unhandled Exception
at 01F35409 -> C000001D

The rip goes through great (much faster than my experience with 0.99b5), but just as soon as I finish up with clicking OK or trying to create a log, that error dialog pops up and EAC vanishes in the background. When checking the directory I was ripping to, the log file has been created, but is devoid of any text.

This is a feature I'd rather have than not have, sooner than later, but I haven't a clue what could be causing it or what the code in the error popup is pointing to as a cause or solution. Any ideas or suggestions on where to go and look for an answer for a non-programmer?

Thanks.

Had the same thing happen, also on Windows XP SP3/Current on all patches. I'm running an all-SCSI setup (including hard drives) if that's any help.

EAC rips properly -- and faster, like the OP said, than its predecessor -- but crashes with an unhandled exception when it attempts to write the log.

Having exactly the same problem. No solutions yet from the EAC boys?

Completely uninstalled 0.99 pb5, installed a fresh 1.0 beta 1, still the same error!

Having exactly the same problem.
EAC 1.0b1
Append checksum in log file: checked
Windows XP SP3 / AMD Athlon

Are all y'all using Athlon XP (32-bit) processors?

I'm having this problem in my old Windows XP-based ripping workhorse, which is powered by an Athlon XP-M processor. (It's a Barton core K7. I'd had it overclocked, but clocked it back to stock once I encountered this problem.)

I even tried a fresh XP install -- to no avail. Nothing seemed to work.

So I installed 32-bit Windows Vista on the same hardware, thinking that perhaps my EAC travails stemmed from some kind of esoteric XP issue.

You can guess what happened next: I finished up my build tonight, proud as hell of my little-system-that-could, and...got the very same unhandled exception error. The same circumstances that all y'all are doubtless familiar with: EAC finished ripping, I clicked "OK" after viewing the status report -- and the damn thing crashed while trying to write the log file.

I've had no problems ripping with 1.0b1 on any of my other systems, one of which includes an Athlon 64 (K8) processor. Yet EAC 1.0b1 predictably crashes on the same K7 hardware in two different operating environments.

If some of you folks will report back and confirm that you're running vanilla (pre-K8) Athlon microprocessors, I think we'll have narrowed things down a bit.

EDIT: I should reiterate that we're talking specifically about creating the checksum here. EAC 1.0b1 can create the log -- sans checksum -- without crashing. It's just when it goes to append the checksum to the log that the shit hits the fan.

Originally Posted by whackamus

Are all y'all using Athlon XP (32-bit) processors?

Well, I'm. AMD Athlon XP 1800+ on MSI board.

EAC 1.0 b1 uses some kind of SSEx (e.g., 2, 3, 4) instruction to generate the checksum. Athlon XP supports only SSE. If someone else will chime in and confirm that (a) they're experiencing the same problem and (b) they're likewise using an Athlon XP (or earlier*), I think we'll have solved this issue.

And -- assuming my guess is correct -- perhaps Andre can code a workaround of some kind for 1.0 b2?


*e.g., Pentium III chips -- like AMD's K7-based Athlon chips -- support SSE-only.

Originally Posted by whackamus

If someone else will chime in and confirm that (a) they're experiencing the same problem and (b) they're likewise using an Athlon XP (or earlier*), I think we'll have solved this issue.

When I use EAC 1.0b1 on my AMD windows xp sp3 system I also get an unhandled Exception at 01EB5409 -> C000001D error.

My system:
Amd Athlon XP 2200+
windows xp xp3 32bit

So this could be an Amd specific error.

greetings,

Ben

I got the same error!
My pc:
AMD AthlonXp 2400+
MSI K7N2 motherboard
WinXp Pro Sp3 (32bit)
You may see the error HERE!
I hope u fix it soon! http://www.digital-inn.de/newreply.p...&p=150620#:21:

Originally Posted by whackamus

EAC 1.0 b1 uses some kind of SSEx (e.g., 2, 3, 4) instruction to generate the checksum. Athlon XP supports only SSE. If someone else will chime in and confirm that (a) they're experiencing the same problem and (b) they're likewise using an Athlon XP (or earlier*), I think we'll have solved this issue.

And -- assuming my guess is correct -- perhaps Andre can code a workaround of some kind for 1.0 b2?


*e.g., Pentium III chips -- like AMD's K7-based Athlon chips -- support SSE-only.

Yes. AMD Athlon XP 2800+ here.

Here's to hoping the EAC folks care to bother coding for the older processors that many of us still use.

Yes, I think there must be something wrong in how I call the IPP functions for generating the hash value. Basically it should autodetect which processor optimizations could be used (even down to none), but there seems to be something wrong...
I will have a look at it!

/Andre

I now have changed something in the IPP initialization (fixed setting to use MMX at max), it seems that there is a problem within IPPs auto-initialization routine...
Please let me know (best directly per email) if the problem persists with the next version!

/Andre

Originally Posted by Andre Wiethoff

I now have changed something in the IPP initialization (fixed setting to use MMX at max), it seems that there is a problem within IPPs auto-initialization routine...
Please let me know (best directly per email) if the problem persists with the next version!

/Andre

Nice. Will try again with my PII when the new version is released. Thanks for looking into it. Good job!

Originally Posted by Andre Wiethoff

I now have changed something in the IPP initialization (fixed setting to use MMX at max), it seems that there is a problem within IPPs auto-initialization routine...
Please let me know (best directly per email) if the problem persists with the next version!

/Andre

Can't wait for the next version cause we cannot rip our cd's!