Can anyone help me with this Jcl error? It is the only thing stopping my code from compiling and running. It keeps giving back a max CC of 12 even though the code is running perfectly.
IEW2736s There is no space left in the directory for DDName Syslmod. Stow of the
Directory entry member name Strbrk failed.
I haven't been able to find a fix for it anywhere , so I feel this is my last hope.
As the message says, the directory for the library on SYSLMOD is full, so your (new) member cannot be added.
If it is a library which you defined yourself, make a copy of the data, ensure the copy worked, then delete and redefine the library with more space for the directory, copy the backed-up data to your newly defined library.
If you are uncertain on how to do these, seek advice from your colleagues/technical support.
If it is not a library that you defined, find out who is responsible for it, and ask that it be extended.
If there are members on the library which you put there and which you no longer need, you can delete (at least one) and continue as a short-term thing.
Related
A file of Delphi's own LIBs has been changed, for a specific need. Since we have several programmers, I need to make sure everyone has this change, and in the future as well.
As the Delphi libs are installed and are not versioned, I need to verify that it is in the correct version.
I wanted to do this before compiling the version.
What I was able to do is create a hash of the file so I assure that it was not modified
{$IF getMD5('C:\Delphi7\Lib\arquivo.dcu') = 'B1C1CBE80477S09AC4C1B39C28FE9619'}
{$Message Fatal 'Version of file .dcu file in Delphi7 Lib is wrong..}
{$IFEND}
That way it does not work, because every moment returns the message of [Fatal Error]
Any idea?
My Delphi time was long ago, but my approach with C++ would be, to add a unique symbol to the lib, that the project depends on. Then, you will at least get a link time error if the symbol is missing (i.e. not your version of the lib is used).
How could this look like (not sure if this is feasible in Delphi)?
In addition to your modifications to the LIB, you also add a function called "MyModificationSentinelABCDEF()" that is empty (the name is not important, just make sure it is unique). Then, instead of the $IF statement you proposed, you add a call to this function and a descriptive comment to explains why it is there and what has to be done if there is an error related to it.
If the function is missing, you should see a compile/link error.
First of all, I've never worked on iOS, so this may or may not be a stupid question, I don't know :)
I have an iOS App, and I need to run it.
In the 'Project Navigator' I have a folder/package called 'Reuse and Platform Libraries'. Inside, I have another four folders but 3 of them seem like missing.
I am not sure if this is the case. I've tried googling their name but without results so I assume they are not some open source libraries.
Can someone clear this up for me? Do I need to install some XCode packages?
Thanks!
I suggest you search the folder of the project for those files, sometimes when copying a project the paths get screwed up because they were set as absolute paths and not relative paths.
If you can't find the files, it's most likely that the library is a private one used by the previous developers, and usually kept out of the project folder so they probably forgot to send it along. I'd suggest simply asking them to send the files over :).
There is also a slight chance they are not needed to run the file, in which case, just deleting them from the sidebar should make the project run.
The Question
There are plenty of manual ways to make WinDBG find mscordacwks.dll without a symbol store (putting the file in the path somewhere, putting it in the same folder as windbg.exe, putting it in my Framework\v folder, specifying the path in WinDBG using .cordll -lp c:\dacFolder, etc.), but they all only fix it for me. I need to fix it more generally for everyone who uses my symbol store.
The possible solutions I can imagine are:
WinDBG be made to check the symbol store using mscordacwks.dll's subfolder name instead of mscorwks.dll's folder name.
SymStore.exe be made to add mscordacwks.dll under mscorwks.dll's subfolder name so WinDBG finds it when it looks there.
Q: Are either of these things possible, or is there another way that I'm not thinking of to solve the problem?
The Background
When analyzing a .NET process, I encountered the (apparently common) problem that psscor2 (and sosex) could not find the appropriate mscordacwks.dll on my machine. The error in WinDBG is:
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
There are plenty of SO questions on this and plenty of good answers, practically all of which ultimately reference Doug Stewart's outstanding blog post, What is mscordacwks.dll?.
Thanks to that, I got my situation all straightened out by obtaining the correct mscordacwks.dll and placing it here:
"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
where I knew WinDBG would look because I had previously tried it with !sym noisy.
So I'm all set now, but I had to put it in that path physically rather than adding it to my symbol server through the normal symstore.exe mechanism. Since my symbol store is used by more than just me, I need to do it the right way for everyone else using the store.
And that's the problem. When I add using symstore.exe instead of going into the above path, it goes into:
"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
The only difference being that the subfolder name is 4E1545CB1bd000 here instead of the 4E1545829a3000 that WinDBG is looking for.
The reason for this is that when adding a binary to the symbol store, symstore.exe uses the PE of the binary to get the image timestamp and the image size. In the case of this particular .dll, dumpbin.exe /headers mscordacwks.dll reveals these to be:
image timestamp: 0x4E1545CB (Thu Jul 07 01:36:11 2011)
image size: 0x1BD000
Hence, the subfolder name 4E1545CB1BD000.
What WinDBG is looking for, on the other hand, is a subfolder based on the image timestamp and image size of mscorwks.dll, not mscordacwks.dll, because the former is loaded into the process, not the latter. WinDBG can't know the timestamp and size of the DAC module because that module is not in the process dump.
As further verification of this explanation, dumpbin.exe /headers mscorwks.dll reveals:
image timestamp: 0x4E154582 (Thu Jul 07 01:34:58 2011)
image size: 0x9A3000
which you can see add up to subfolder name 4E1545829A3000.
Knowing this, now it makes a lot more sense why all these many versions of the mscordacwks.dll that people keep running into seem to be missing from Microsoft's symbol servers. I'm sure they're there, it's just that WinDBG and psscor2 can't find them because they're picking the wrong subfolder name. Why it even bothers searching the symbols path is beyond me since it's guaranteed never to find it!
So that's my challenge. Can I somehow force symstore.exe to add mscordacwks.dll using the PE info of mscorwks.dll? If not, am I missing something about WinDBG and psscor2, might there be a way for them to know the correct timestamp and size of mscordacwks.dll even though it's not loaded (and a way for them to actually use those instead of mscorwks.dll)?
Since no other solution has appeared and my workaround seems to handle everything nicely, I'm just going to keep on with that, and I would recommend anyone else who never wants to see the annoying Failed to load data access DLL, 0x80004005 error again do the same.
So to make this work for you (and everyone who uses your symbol store, so I really wish Microsoft would do this to save us all a lot of trouble) simply place the compressed DAC file (mscordacwks.dl_) by hand into the correct path within your local SYM store.
Here are the steps I follow to accomplish this:
In WinDBG do a !sym noisy
In WinDBG do a .cordll -ve -u -l
In WinDBG do another !CLRStack or other psscor2 command if necessary to force it to load symbols again
The symbol search logging will reveal the dll it’s looking for and where it’s looking in your symbol store by showing lines like this: C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll which indicates two things:
you need the 64-bit mscordacwks.dll of version 2.0.50727.4216; see https://stackoverflow.com/a/12024171/1910619 for ways to get it
it needs to go in a subfolder called 4E1545829a3000 under a folder called mscordacwks_AMD64_AMD64_2.0.50727.4216.dll in your symbol store
Once you obtain the file, rename it according to the name WinDBG is looking for, e.g. "mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
Manually compress this file using makecab.exe like this: makecab /D CompressionType=LZX /D CompressionMemory=21 mscordacwks_AMD64_AMD64_2.0.50727.4216.dll mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_
Copy that compressed file to the expected place in the symbol store. (That you found in step 4 above, so C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_ in our running example here.)
You have to put the CLR dll and the associated mscordacwks dll in the same folder and register the CLR dll with symstore.
In that case symstore will add the clr and the mscordacwks dll on the symbol store.
More importantly, it will use the timestamp and file size of the clr dll to create the mscordacwks subfolder, so windbg can find the mscordacwks dll when debugging a dump.
The mscordacwks name must follow the mscordacwks_ARCH_ARCH_fileversion pattern, otherwise symstore won't add it to the symbol store.
I didn't find any documentation on that feature so it may be removed in the future.
Here is the command and the symstore output:
symstore.exe add /o /f 4.6.1076.00\clr.dll /t clr.dll /s \\mystore\microsoft
SYMSTORE MESSAGE: 0 alternate indexers registered
SYMSTORE MESSAGE: LastId.txt reported id 0
SYMSTORE MESSAGE: History.txt reported id 58228
SYMSTORE MESSAGE: Final id is 0000058228
SYMSTORE MESSAGE: Copying C:\Users\build.robot\symstore\4.6.1076.00\clr.dll to \\mystore\microsoft\clr.dll\56D79ED4990000\clr.dll [Force: T, Compress: F]
SYMSTORE MESSAGE: Copying 4.6.1076.00\mscordacwks_AMD64_AMD64_4.6.1076.00.dll to \\mystore\microsoft\mscordacwks_AMD64_AMD64_4.6.1076.00.dll\56D79ED4990000\mscordacwks_AMD64_AMD64_4.6.1076.00.dll [Force: T, Compress: F]
SYMSTORE: Number of files stored = 2
SYMSTORE: Number of errors = 0
SYMSTORE: Number of files ignored = 0
I am trying to resolve a problem with a set of packages that apparently have dependency issues. Occasionally during a Build All, I get this error:
Delphi "E2161 Error: RLINK32: Error opening file ________.drf "
What does it mean / indicate, and what is a "drf" file?
It looks like this turned out to be the main problem / solution.
Open up all the packages for which you have source code, and specify the compile option:
'Rebuild explicitly' instead of 'Rebuild when needed'.
In addition to the Solving the 'cannot find drf file' problem when compiling packages article, I also came across Delphi bug report #44134, in which a commenter mentions that the problem stems from having your .dpk files in the same directory as your .pas files when that same directory is in the library path and "rebuild as needed" is enabled.
You thus have three options for fixing this problem:
Turn off "rebuild as needed". This seems to be the most common solution.
Put your package files (*.dpk, *.dproj) into a separate directory and then reinstall the packages. I have done this, with success.
Remove the directory containing your .dpk and .pas files from the library path. Note that Delphi will add it back again in certain circumstances, including when you install/reinstall your package.
Hmm... never heard of them. I just searched the project that inspired the question you linked to, and there's nothing in there with a "DRF" extension. Checking here doesn't turn up anything Delphi-related. But the fact that it's a linker error, not a compiler error, would lead me to guess that the first two letters stand for "Delphi Resource."
Try a search through your project's directory tree and see if you can find anything with a DRF extension. If so, try opening it with a text editor to see if it's readable, and if not, try a hex editor if you know anything about reading binary file formats. See if you can make any sense of it.
If you don't find any, then Delphi's probably getting it from somewhere in the code it's compiling. Try running a grep search for "DRF" on your directory tree and see if it turns up anything.
From http://www.delphifaq.com/faq/delphi/delphi_ide/f157.shtml :
When you compile with packages, you
can specify which packages should be
considered for linkage. The package
requirements of the project get stored
into a temporary Windows resource file
with a .DRF extension.
Whatever that file with the many underscores is, the linker is most probably searching it in what it thinks the tempdirectory is (you can confirm this using filemon). The explanation at DelphiFaq, where a misdefined %TEMP% is the culprit, is as likely as any reason.
Sometimes the problem was file access permissions.
A workaround was run Delphi as Administrator.
Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.