IPB

Welcome Guest ( Log In | Register )

EAC 1.0beta 3 crash upon log file creation, unhandled exception 02F39F09 -> C000001D
Harlequin91
post Jan 4 2013, 15:33
Post #1





Group: Members
Posts: 3
Joined: 4-January 13
Member No.: 105580



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!
Go to the top of the page
+Quote Post
 
Start new topic
Replies
ThePampers
post Jan 4 2013, 19:15
Post #2





Group: Members
Posts: 19
Joined: 26-April 09
Member No.: 69283



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.
Go to the top of the page
+Quote Post
db1989
post Jan 6 2013, 02:32
Post #3





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (ThePampers @ Jan 4 2013, 18:15) *
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?
Go to the top of the page
+Quote Post
Rollin
post Jan 6 2013, 09:30
Post #4





Group: Members
Posts: 196
Joined: 5-March 08
Member No.: 51815



QUOTE (db1989 @ Jan 6 2013, 05:32) *
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
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 27th November 2014 - 03:12