cdrtfe cygwin1.dll error, 1.5.6.0
Burn optical discs in various formats
Brought to you by:
kerberos002
Menu
▾
▴
1 Attachments
#79 cdrtfe cygwin1.dll error, 1.5.6.0
cdrtfe:
Error!
(X) cdrtfe has detected a problem . Either the binaries (cdrecord/mkisofs) are corrupted, or there is a problem with the cygwin1.dll (version conflict or incompatibility).
may I suggest that during your build or in your makefile you copy the latest cygwin1.dll file into its proper place from wherever it comes from (if it's in a version number dir, that's a pain to deal with)?
or that you make 2 directories in the installer file tree like win9x\ and winxp\ and put the appropriate versions of cygwin1.dll into those directories, and in the installer you can copy the appropriate file into place as the main dll into cygwin\ and/or cdrtools\
EAccessViolation
this means that it might be an array out of bounds exception, or a pointer that has been messed with all wrong like a C pointer pointing to an array and somehow going off the deep end of the array...
my drive wasn't listed in the dropdown list of drives - list completely blank. a blank JVC dvd was placed in it. just found out debug mode seems to work. that access violation could be a string length not being completely allocated for a switch for example. C strings use a NUL terminator '\0' but PASCAL needs no such thing. the Win32 API uses nul-terminated C Strings for LPCTString, LPCString, LPString arguments, and the TString type of arguments can be wide characters (2-byte) or narrow (1-byte) characters (C short type or char type). I hope this helps. maybe this info I am giving can help trace down the bug. I am going to look at the log and look at the source, if I may, to try to get at the source of the problem.
[0045C8D6] Forms.TApplication.Run (Line 7793, "Forms.pas" + 16) + $3
it's near the end of this. I looked at the offset address, and this is where the crash came.
Last edit: Jim Michaels 2016-11-18
If you get this error message, it is a cygwin problem not a cdrtfe problem. Start cdrtfe in debug mode to get the output of the commandline that failed. Maybe you can get a hint of what went wrong which may help you to find a working cygwin version for your system.
The EAccessViolation is probably caused by the failed drive detection as cdrecord won't work without cygwin.
In general, each download already includes the correct cygwin1.dll for the supported operating system:
cdrtfe-1.5.6-legacy.exe:
cygwin 1.5.25 for Win9x/ME/2k, in some cases it may be necessary to use cygwin 1.5.14.
cdrtfe-1.5.6.exe, cdrtfe-1.5.6.msi, cdrtfe-1.5.6portable.exe, cdrtfe-1.5.6.zip:
cygwin 2.3 for WinXP/Vista/7/8/8.1/10
I have successfully tested the downloads under every supported Windows version except for Vista which I don't have access to, so there's no general problem with cygwin under these systems. As cygwin is a quite fragile thing, any specific anomaly of your system could cause cygwin to fail. And if cygwin fails on your system then cdrtfe won't work. However this is the wrong place to get support for fixing your system, in order to get cygwin running.
a failed drive detection is not the cause of a windows 0xc0000005 windows error "access violation". I outlined the causes (well, there are a few more I can think of now). I looked for the file mentioned in the cdrtfe.log file "Forms.pas" but it does not exist, so I suspect it may be something built into the compiler or was not submitted to git. may I look in frm_main.pas for clues? I don't know if you plan on making this a commercial application or not in the future.
this is XP 32-bit pentium D.
this is not a support question, I am not out to "fix my system" (I do computer repair and software development for fun and profit and for the sheer challenge).
it should not be me providing the varying versions of cygwin1.dll, it should be your installer. if you need help with that, I can look up some things in the installer docs and make some recommendations if docs are online.
this happened the 1st time I tried 1.5.6.0, if this helps any.
the dll clearly works under debug mode, but not under release. so this is not a cygwin1.dll issue I think.
the access violation may be coming from some array, string, pointer access via win32 call, or structure (like something near the end without allocating enough memory for it - windows structures or C structures can do this) access outside of an allowed memory boundary, somewhere in between the time the start button was pressed in frm_main.pas, and either the mkisofs or cdrecord process was started. I had the program in on-the-fly, udf, dao, single-session, doing a DVD-R.
one thing that's coming up soon, is that I have some new 16x DVD-R's that it would be interesting if I got full bandwidth out of this old box for, but it may be ATA133, and it's normally really slow. I usually get 5.6x-8.1x on an 8x DVD on this box.
Last edit: Jim Michaels 2016-11-21
"Zugriffsverletzung bei Adresse 00561069 in Modul 'cdrtfe.exe'. Lesen von Adresse 00000000"
"Access violation at address 00561069 in module 'cdrtfe.exe'. Read address 00000000"
this means something either:
returned a value of 0 or NULL and then tried to use that as an address (string?) to read from
was initialized with 0 or NULL (pointer? win32 or COM+/.net call? C?) and then tried to use that 0 address to read something from (by the way, that space is reserved for interrupt vectors)
an HRESULT is a pointer. the pointer might be used by windows as just a number, or it might be used for something else. H anything is basically a HANDLE to something. like HWND is a window handle.
Last edit: Jim Michaels 2016-11-21
it's XP Media center edition 2005. original XP was in 2002. media center edition has some odd functionality that's broken with regards to tv guide and recording. so my windows exe's,dll's are later than xp home, pro. could be part of the fix or part of the problem or neither.
Yes, it is. This cygwin problem causes every cygwin program to abort before you get any useful output. When cdrtfe encounters this error it shows the error message and aborts the initialization. If you like to look into the source code:
f_init.pas, function CdrtoolsWorking (line 614) detects the error, shows the error message, Result is false
f_init.pas, function CheckVersion: Result is false, because CdrtoolsWorking is false (line 658 or 680)
f_init.pas, function CheckFiles: Result is false, because CheckVersion is false (line 347)
form_main.pas, procedure TCdrtfeMainForm.FormCreate: FAction only gets initialized if CheckFiles is True (lines 4990 and 5045)
If you now click the Start button, FAction.Reset is called. However, FAction hasn't been initialized. Boom. Access Violation. See form_main.pas, line 5561, which is the exact line from your error log:
[00561069] frm_main.TCdrtfeMainForm.ButtonStartClick (Line 5561, "forms\frm_main.pas" + 9) + $6
Granted, perhaps the Start button should be disabled when this error occurs, but how can you expect the program to be working correctly, if you get the error message that some of the core components are not working and the drive list is empty?
No. It's just a small hobby project.
As I have written in my previous comment, the installer provides the correct cygwin1.dll for each supported system. Depending on the system itself, the installed software and many other conditions another version may be necessary. However, this isn't something that can be detected by the installer. For more information about software interfering with cygwin search for 'cygwin bloda'.
if (emptyDriveList) {
} else {
}
looks like the need for if-then-else in a couple of places.
remember, if you get a 100GB disc, takes 31 hours to run 90GB worth when I tried it. that was no joke. drive gets hot and so does disc. but biggest question is, will windows read a 100GB disc? I think that functionality is not there yet. windows IMAPI works for 50GB.
strange. 1.5.6.0 now comes up twice now with my dvdrw drive listed after setting some defaults, even though it did not before. try again with cdrtfe.ini deleted?
I never doubted that. But this isn't anything that cdrtfe can influence. cdrtfe does nothing special. For writing it uses cdrecord. For reading it uses normal Windows API calls.
How should I know? I don't have the appropriate hardware to test. You'll have to find someone else to ask this question.
As I have often said already, I think that this erratic behaviour is somehow caused by your system. Or something that is special to your system. Maybe a special software you have installed or whatever.
I know, and that is no joke, that cdrtfe, the cdrtools and cygwin work flawlessly on several systems.