TransferThread Runtime Exception! - Message: EInvalidOp

[Semmel]

Hi *.*, 

 

since a few days sometimes I got this error ("TransferThread Runtime Exception! - Message: EInvalidOp") while creating an image file from disk (to hdd).

 

The disks are not write-protected or something else; but burned by myself.

Hard- and software was not changed (XPSP3, ImgBurn 2.4.4.0, DVD: HL-DT-ST DVDRAM GSA-4163B A104 (ATA))

 

Anyone an idea what's suddenly wrong? (last log is attached). Thx in advance.

 

ImgBurn-Log.txt

[LIGHTNING UK!]

No offence but it's a waste of time reporting issues in old versions... and that one is 4 years old!

 

Install the current release.

[Semmel]

No offence but it's a waste of time reporting issues in old versions... and that one is 4 years old!

 

Install the current release.

 

First of all: I thank you for response.

 

No offence but in my opinion there's no good reason to renew a system continously - especially not when it is running stable and without any bugs or crashes. And the same applies to ImgBurn (in my "four years old version" [V2.4.4.0]) - it ran without any problem until a few days ago. And that's the reason I asked for it while neither Hardware nor Software are changed.

 

But (contrary to my belief !) I now have installed the latest version - and there is the same problem as in my "four years old version": at the end of getting a created image from a cd/ dvd, imgburn breaks with an error and creates a bugreport.

I've attached two of them (from two different dvd) and maybe now it's not time wasted to take care of the problem.

 

Thx in advance, Semmel.

 

 

And btw.: "DVD Shrink" (V3.2) creates an image of these two (and others) dvd without an error-message.

bugreport1.txt

bugreport2.txt

[LIGHTNING UK!]

Turn off 'capture graph data' in the settings.

[Semmel]

done but no changes.

The next trouble since today (with and without "capture graph data' in the settings"): I click on "create image file from disc" and I get an error message (see below). I only want to take an *.iso-image from a "normal" dvd-r containing two films - recorded with a Panasonic (DMR-EH575) from TV, so there are no limitation or copyrights e.g..

I don't understand these difficulties, which are completely new for me since I first used ImgBurn a long time ago.

And why don't warn the version 2.5.8.0 (like version e.g. 2.4.4.0 and older), when it found a FAT partion like this:
"W 16:29:36 Drive C:\ (FAT) does not support single files > 4 GB in size"?

This is missing in the latest version! ImgBurn only warns when it found a FAT32 partition.

 

------------------------------------------------------------

 

[LIGHTNING UK!]

Can you post the new bug report with the graph data bit disabled please?

 

Is that 'fat' c: drive less than 4gb in size? In theory, that's the only time it shouldn't warn you about the max file size limit of a fat/fat32 drive.

[Semmel]

I would if I could. 

 

But since yesterday always comes this message "Sorry, using Read mode ..." (as in post #5 described) when reading DVD's and ImgBurn terminates immediately - without creating a bugreport.

Today I have uninstalled the version 2.5.8.0 completely and then reinstalled. Then I set all settings to default. But nothing works: the error (see #5) happens - with "capture graph data" on or off - and ImgBurn aborts.

With some audio CD's, the program starts and write:
"Reading CD-Text information ...
Analysing Tracks ... (Session 1, Track <x>)"
where <x> is then incremented, but only up to Track 2 - maximum Track 3 - and then the program freezes/ depends completely on. Possible that the latter has to do with copy protection, because other today tested audio CD's are processed properly.

 

But maybe these additional information can help you.

[Semmel]

[...]

Is that 'fat' c: drive less than 4gb in size? In theory, that's the only time it shouldn't warn you about the max file size limit of a fat/fat32 drive.

 

'Normal' FAT-drives or partitions (FAT, FAT12, FAT16) are always less than 4GByte (http://en.wikipedia.org/wiki/File_Allocation_Table#Original_8-bit_FAT) - or am I wrong? And in my case it's a little 35 MByte-DOS partition.

 

And if the options of "File Splitting" is set to "Auto" it is theoretically possible to save on FAT, doesn't it?

[LIGHTNING UK!]

I can't say that I really remember the max size of partitions using those old file systems, I haven't used them in years.

 

In any case, it's pointless warning about a file system only supporting files

[Semmel]

Pointless? It's irrelevant whether a hard drive, partition, or the remaining space is insufficient. So should - logically - even HDD (or partitions) are being listed.

But anyway that was just a question on the sidelines, which is not related to the actual/ original problem.

And as always: you're the boss.

 

[LIGHTNING UK!]

The 'Invalid Floating Point Operation' error is caused by a bug in the compiler and it isn't something I can fix without upgrading my version of the development environment to a version that's fixed it. I've never run into it personally.

 

I get bug reports sent to me on a daily basis for the same problem at the exact same line in the code - you're the first person I've told to turn 'Capture Graph Data' off (thus getting passed the line it normally crashes at), but it appears that it then just crashes somewhere else.

 

So at this point, I'm sorry but there's nothing I can do for you.

[Semmel]

Then I wonder why I should update first !?!?!?.  

Now I have the original state made by a previous hdd-mirror. Lo and behold, IMGBurn 2.4.4.0 is running properly at the same DVD's if 'capture graph data' in the settings is turned off.

Believe me: I knew why I'll not changing a running system - and in this case: I will use the 'damned four years old' version for a long time in future !

 

And no offence but I thank you for replies, honestly.  

[LIGHTNING UK!]

Because I'm not going to look at a bug report of an old version... full stop.

 

Changing the 'capture graph data' option may get around it for a while but as it's a compiler issue, you may well run into it elsewhere.

 

Even if you *think* 2.4.4.0 is ok, you only have to check the 'Fixed' items in the changelog to see what's been worked on since then. It's far from perfect.

[Semmel]

Even if you *think* 2.4.4.0 is ok, you only have to check the 'Fixed' items in the changelog to see what's been worked on since then. It's far from perfect.

 

Certainly, the 2.4.4.0 is not perfect, but unlike the latest version at least it works with my 'special cases'.

And the latest version is also not flawless - no matter whether the interpreter is located on or the programming.

 

And what in life is already 'perfect'?