I'm using C++ Builder 2009. I have the indy system, core and protocol installed in my environment. Recently, about once a week I get a message of:
Title: bds.exe - Entry Point Not Found
Message: The procedure entry point #Idstack#TIdStack#Make$qqrv could not be located in the dynamic link library IndySystem120.bpl
The solution I've been doing is closing the current project. Rebuild/reinstall the 3 indy projects (core, system, protocol) then everything works fine for about a week.
The troubleshooting steps I've tried so far was searching my system for bpl files related to the Indy system and removing them before doing a clean install (in case there was some sort of pathing issue). I then ran Builder as administrator and installed the components. I thought I solve the problem, but alas I'm having the issue again. Does anyone have thoughts on anything else I can try to solve this more permanently?
The TIdStack.Make() method was removed in Indy 10.5.7 for the RAD Studio XE release. If you have upgraded your installation of Indy 10 and have newer package versions floating around your system, that can interfere with any packages that were compiled to use the original Indy packages that shipped with C++Builder 2009.
So I had the problem for a couple of weeks and had to do several rebuilds of the library. I run the environment through a VM and found that my VM was low on space. I found that by clearing up some space on the drive that the problem went away. I've been working in the environment for over a month now without having to rebuild, where I used to have to do it 1 to 2 times a week.
Related
I'm trying to move a project that was done in a previous version of C++Builder to 10.1 Berlin (I am using the trial version of C++Builder).
The project was converted and compiled succefully with minimal efforts. Then I got the well-known linker LME288 problem, but it was resolved by starting C++Builder as an administrator.
But now, when I start the application, I get a message box saying "Abnormal program termination" at the very beginning - even before the main window appears on screen.
The situation is the same for debug and release versions, under IDE and as standalone. When I start the program inside the IDE, and set a breakpoint at the very first statement, the error message appears before this statement.
I have Windows 10 Pro, 64-bit. C++Builer 10.1 Berlin trial. It shows the only accessible platform is Win32, but I don't know if this is a reason for an error. The program worked fine for previous versions.
Could anybody advise me what to do? Is there a systematic way of investigating the problem?
I have tried all recommendations I could found - use debugger, show us the code, try reinstalling software or Windows, upgrade to latest updates, etc. But I have never seen a systematic approach.
Here are a couple of things I had to do to get my project working.
1) Start a new project. For some reason old projects can get corrupted and produce strange errors. I recommend starting a new project and adding your files to it.
2) Use an old version of borlndmm.dll The version provided with C++ Builder 10 produced crashes for me that made no sense. I overwrote the provided copy of borlndmm.dll with a copy from XE6 or XE8. That solved my problem.
Hopefully one of these will help you.
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
I know that generally it has always been possible to do a side-by-side installation of multiple Delphi versions on a single computer. I have often done that ever since Delphi 1.
However, after installing Delphi XE7 on a computer that had XE6 installed, I get stange errors (e.g. AV's) when trying to use FireDAC or FDExplorer from XE7. At first sight everything is OK, but when trying to connect to a database, the connection "hangs", or you get an AV.
Everything works like normal from XE6.
The installation of XE7 was done using default settings, and XE6 was installed including all updates already prior to installing XE7.
Any advice?
I did experience same problem myself when first having installed XE7 and defined some connections to Oracle and then installed Delphi XE3 in order to do some stepwise upgrades of third-party components.
Since I also needed FireDAC I installed the Firedac add-on to XE3, but when I installed the FireDAC add-on to XE3, I lost the connection definitions and when trying to define new connections I got error message that the FDconnectionDefs.Ini was not writeable in the directory (in program files(x86) Delphi/FireDAC_XE3 area.
After checking it turned out that the installer had overwritten the registrations in \HKCU\Software\Embarcadero\FireDAC key.
Turns out the same parameters in that key is reused.
So conclusion is, don't install FireDAC in elder versions, uncheck that option when installing XE4-XE6.
(I have sent a suggestion to Dmitry Arefiev that the FireDAC key should have defined new subkeys, one for each Delphi/C++ version so several installations could be used in parallell as before.
Now that is broken :-(
To clean up, find your correct FDConnectionDefs.ini and change necessary keys.
It may also be possible that the software also has been overwritten.
I did a repair on the latest version of XE7, and after some merging of FDconnectionDefs.ini files I finally got it working
After installation of the Update 3 for Delphi XE2 I get the following error and the IDE does not want to start.
I tried installing the standard Delphi XE2 with Update 1 and the problem persists. Do you have any idea what is causing this?
It looks like the file got corrupted somehow. I just checked my Win 7 64-bit Pro, and there are two copies of msimg32.dll found, 1 each in System32 and SysWOW64, both dated 7/13/2009 and version 6.1.7600.16385. So it appears they haven't been updated recently.
The actual error message you're getting is related to access denied, and the second one is DLL initialization failed, which is probably a result of the first one; the IDE isn't loading because the DLL can't be loaded.
My only suggestions are: 1) open a support case with Embarcadero (as an installation related problem, the support is free), or 2) reinstall Delphi from scratch, run it once to create registry entries, and then reinstall Update 3. I don't think anyone here is going to be much help; I'm not finding anything in searches related to Update 3 and this dll, so it seems to be just you having the issue.
Just delete msimg32.dll in delphi_install_dir\Embarcadero\RAD Studio\9.0\bin folder.
This file shouldn't be there if you are doing everything correctly.
After many years of trouble-free use, Delphi 7 is now throwing an Access violation at address
40233A3E in module 'vclx70.bpl'. Read of address 0000021C.
When starting the IDE, the default empty project and unit/form appear and compile and run fine.
I'm developing Windows apps, running on Windows 7 (x64).
I haven't installed any new packages or tools in many, many months.
I stopped, dead in the water, unable to work.
Any suggestions other than a complete rip and re-install (which takes many hours...)
EDIT: I un-installed and re-installed Delphi 7. Now I'm getting Access violation in vcl70.bpl. I would have thought that uninstalling D7 would completely remove all of its libraries, etc... Are there folders that I should manually delete after uninstalling D7?
Problem fixed (and major machine rebuild averted)!
Gerrit Beuze of ModelMaker Tools suggested elsewhere:
Remove all .dsk (project desktop) files for the project you try to load, Temp remove all *.dst (desktop files) from C:\Program Files\Borland\Delphi7\Bin
After performing these steps, the problem appears to have been fixed.
A read at that low a memory address is typically a problem in a third-party component. However, you say you haven't installed anything new in months.
The other thing that's strange is that you're getting the error in vclx70, which is one of the CLX libraries. Are you doing anything using the CLX (leftover cross platform - Kylix) forms or dialogs?
If not, you might do a search in your source for QDialogs, QForms, or any of the other units in %PROGRAMFILES%\Borland\Delphi7\Source\Clx, and see if something mistakenly was added that you didn't intend that's pulling CLX into your project. If so, change it to the VCL version instead (by just removing the 'Q' from the front of the unit name in your source).
EDIT: You might try going into the registry (D7 would be HKCU\Software\Borland\Delphi\7.0) and temporarily changing the name of the delphiCLXide entry in Known IDE Packages to something else (put an underscore in front of the name or something). Then start the IDE. You should get an error message about Delphi being unable to load the package, and asking if you want to try and load it again in the future. Answer 'Yes', and let the IDE continue to load. Then try again with your project and see what happens.
The step above removes CLX temporarily from loading in the IDE designer. (Don't worry, you can just rename the key again to put it back if it's not the problem. If it doesn't come back, make sure the IDE didn't add an entry in the Disabled Packages entry; if it did, just remove it.)
If this works, you can open the project options (.DOF) file for your project, and remove the CLX libraries from the Packages list. This prevents it from being included when your project is loaded.
Once you've established whether the problem actually
My first suggestion would be to use XP Mode or another VM infrastructure to run such an old Delphi version on Windows 7 (I do it that way).
Another potential method is to use the compatibility settings in Windows 7 to set it to XP and to exempt the Delphi 7 process from DEP (data execution prevention) policies the system may otherwise impose. I've had some trouble with enabled DEP with older Borland IDEs and also VS 2003.