EAC 1.0beta 3 crash upon log file creation, unhandled exception 02F39F09 -> C000001D Options

[Harlequin91]

Hi! Although I have been a regular user of EAC, I am new to this forum. Thus, I apologise for any stupidities that I may commit!

I've been using EAC 09beta4 for years but recently decided to upgrade to 1.0beta3. Of course, I ran into an issue that, after days of trying and searching the web, I have not been able to resolve.

The issue is the following: after ripping and compressing, the log shows that everything went OK and that no errors were produced. However, when I try to save the log file, EAC crashes with the error "unhandled exception 02F39F09 -> C000001D" (sometimes 02F29F09). Apart from the fact that this drives me crazy, it prevents me from documenting a successful rip.

When EAC crashes, a log file is written but it is empty.

The details:
- I run Windows XP (in french, the same machine as before; fully updated)
- about 1 in 10 times, I can save the log file without EAC crashing; after about 40 trials I have not identified an obvious cause
- changing the optical drive does not make a difference
- gap detection and writing a CUE file or not, does not make a difference
- using the internal aspi interface or wnaspi32 as external does not make a difference
- uninstalling EAC and deleting the registry key, followed by a fresh install does not make a difference
- compressing using LAME (3.90.3 or 3.99.2.5) or FLAC 1.2.1b does not make a difference
- writing CRC values or not does not make a difference
- writing the log file to the folder used to rip or not (or for that matter a different HDD, or the desktop) does not make a difference
- automatically writing the log file or manually doing so after the rip has completed, does not make a difference
- this behaviour is seen with multiple, original CD's (no exceptions)

I could copy-and-paste everything but that does not seem to make sense. Let me know what would be of help.

One final bit of unexpected behaviour; when I manually try to write the log file to the pre-specified folder used to rip (D:\EAC\Ripping) with the output file pre-specified as "%albumartist% - %albumtitle%\%tracknr2% - %title%", hitting Save actually moves the Explorer into the %albumartist% - %albumtitle% folder rather than saving the %albumartist% - %albumtitle%.log file.

I've looked hard but cannot find the solution. Thanks for your help!

[Rollin]

Is option EAC Options->Tools->Append checksum to status report enabled?
If it is enabled, disable it and try again.

This post has been edited by Rollin: Jan 4 2013, 17:00

[ThePampers]

Yep, check the 'Append checksum to status report' flag and change the setting.
Old processors (like AMD Barton step for exemple) can't create the CRC at the bottom of log.

[Harlequin91]

Thanks! I did as you told me and .... no problems with 3 consecutive CD rips.

I messed around for 5 days and you manage to fix it in minutes! Great help!

I'll run a few more and let you know.

[Harlequin91]

Hi Rollin and ThePampers,

Thanks a million. I've now ripped more than 10 CD's and the problem has gone.

You're great!

[db1989]

Old processors (like AMD Barton step for exemple) can't create the CRC at the bottom of log.

This is something interesting I’ve never heard about. I presume it’s due to the calculation utilising some newer added set of instructions (SSE, etc.) that these CPUs don’t have?

[Rollin]

I presume it’s due to the calculation utilising some newer added set of instructions (SSE, etc.) that these CPUs don’t have?

Yes. And Andre already know about this. See here http://www.digital-inn.de/exact-audio-copy...tion-error.html