I have embarcadero radstudio xe8 on a windows 10 machine. Everything was working perfectly till about 2weeks ago. Everytime I try to start Delphi xe8 I get an error :"Exception EOSError in module rtl220.bpl at 00050A4D.System Error. Code 111. The file name is too long. " I tried reinstalling a couple of times and I even tried installing appmethod but I still get the same error.
What can be the problem?
I've had the same issue today. I've traced it to a GetAdaptersInfo() call, and it turned out that for some reason (VirtualBox is my main suspect) I've had over 50 network adapters registered on my system. Removing all of them fixed the issue.
There is not enough info in your question in order to tell what exactly is wrong. Try using Process Monitor in order to check what files Delphi is trying to access. It will also show the errors of these file operations.
as they uri2x tell you the problem is that RAD Studio having issue with many network adapters registered more than 20 will not work properly you will have problem with debbuging and run project and you may find many cmd.exe process running in your system
delete duplicate and non needed network adapters registered on "Control Panel\Network and Internet\Network Connections"
that will fix your problem
This may be of help. I had a similar problem, error code 5 Access is denied. This turned out to related to a thread started to test an internet connection on an embedded panel (using BeginThread). If the user exits the form (which is testing the internet connection) immediately after displaying the form, the AV occurs.
On my development PC, the internet connection test was successful...and so fast I never saw the problem! After struggling for several hours, I finally tracked it down to this thread and reproduced it by disconnecting my network cable.
The solution was straightforward: When exiting the form (eg. in the FormDestroy event) ensure the thread is definitely not running before continuing.
Related
First time debugging from PC to Mobile Phone work fine, when try again get error.
Any solution how fix this when try more debugging.
Add -debugport=54321 to Run->Parameters Parameters. By the way, the "inconsistent certificates" message is because the apk on the device was compiled with a different version of Delphi than the one you are using right now. You will have to uninstall it from the phone first. You can also use -cleaninstall in the Run->Parameters Parameters field.
There is no easy and fast solution.
You may need to:
Restart IDE
Kill adb.exe
Restart Windows
Restart device
Sometimes you will be able to debug again after doing only some of the above steps, however often you will need to do all of them.
Since every try takes plenty of time, I found out that complete Windows restart + device restart is the fastest thing to do.
With Delphi 10.3.3, it is enough to restart the device. After restarting the device problem goes away. It seems after the cancelation of code execution of the project debugged, the debugging service on Android continues to run. At this point, when new debugging started, IDE tries to run a new service with the same id of previous running service.
I have an XE8 project that (is supposed to) access an Interbase server running on the same machine. A few days ago it was working fine, but has developed the problem that if I attempted to set the Connected property of a TIBDatabase component to True, either in the IDE or in code at run-time, I get the error:
Connection rejected by remote interface
Attempting to connect to the server using the IBConsole utility also produces this error.
I've cleared as much of Interbase as I can find from the machine & its registry and re-installed it but the problem persists. Googling the message text finds a modest number of things, but I've tried the few suggested solutions to no useful effect.
Btw, the PortQry utility confirms that port 3050 is open and that the gds_db server is listening.
My question, obviously, is does anyone recognise this symptom and know how to fix it?
I eventually found the cause of this problem. I have an instance of the Firebird server installed on the problem machine and set up as a service, and at some point recently, its Startup Type had been changed from Disabled to Automatic and the fact that it was running was evidently causing the IB server to misbehave. Reverting it to `Disabled' caused the problem to vanish.
I imagine that it was actually the FB server that was the 'remote interface' that was rejecting the connection.
We've got an application written in Delphi that uses Delphi On Rails and acts as a server and communicates with clients using HTTP, JSON and websockets. We ran into some issues lately and it's hard to debug them and find the problem's source.
Using Wireshark for traffic analysis, we could see the following behaviour: There's a request from a client (HTTP GET for a file). Usually, we process that request and send a HTTP status code, the file (if not cached) etc. However, we have a reproducable problem where there's only
the request from the client, a TCP SYN from the server, but after that, the server sends a RST packet and the TCP communication stops.
The strange thing is, we can reproduce the problem quite well (although the files where the RST packet disrupts the communication differ) and it mysteriously vanishes in one of the following cases:
In debug environment (Delphi IDE), disabling madExcept
In release environment, not patching the executable with madExceptPatch
Give focus to a different window than the main application window.
As we had some problems with Delphi On Rails and had to do minor modifications to it to avoid access violations and debug exceptions, I suspect DOR to be the culprit and some strange memory corruption or uncatched exception to be the bug, but it's still confusing, especially the fact that the problem vanishes if we change focus.
My main question is not how to solve this problem, but how to debug it and where to look for problems. The source of the TCP reset also puzzles me, as we don't run into the usual procedures that process requests in that case and it seems like either DOR or something else (the application, Winsock, OS) resets the connection by mistake.
For completeness, as it might be related, here are issues that I reported at the Delphi On Rails project and a forum thread where I asked the madExcept author about the problem: Issue #6, Issue #7, Issue #8, forum entry.
As a test, we checked out some older DOR sources from version control where no connection issues were known, and it works without showing any of the above problems.
So we decided to solve the problem the other way round: Rolling back the DOR specific source code (about 20 files) to the last stable version and "re-updating" it piece by piece until the error will occur again. If this happens, we can
Go back to the latest working version quickly
Hopefully be quite close to the original DOR sources so we can react on updates on the library.
Analyse the occuring error and report an detailed issue (and perhaps even a solution) to the DOR project.
EDIT: We could now update all but one file back to the old state without getting connection issues. The file that creates problems is dorSynchronizer.pas, more exact it's r179 of this file that caused the issues - threads were changed from Windows API to Delphi TThread there. We'll investigate this further and might add an issue to the DOR project in the next days.
EDIT2: It turned out that DOR uses the deprecated procedures TThread.Suspend and TThread.Resume that can cause undefined behaviour. I reported an issue to the DOR project.
I was hoping someone can point me in the right direction regarding an issue I am having with the message "Error creating window handle". I know this usually points to a memory leak problem with the code, however this only happens on a single machine. If the code was the issue, I would be expecting it to happen on other machines as well.
I have other machines that this application runs on that do not run into this problem. I have tried reproducing in on my development machine and other machines in the office. Neither has been successful. I have tried watching the memory in Task Manager on the offending machine and it does not skyrocket up before it throws the error.
The offending machine is running Windows XP Professional SP3. Any ideas on how to proceed would be great.
Thanks
I have just had the same problem in two different applications. For us, the problem was triggered by setting the Windows theme to "Windows Classic" rather than "Windows XP Style". The control that fails is a System.Windows.Forms.ListBox inside a Developer Express XtraLayout container, and our fix is to replace it with a DevExpress.XtraEditors.ListBoxControl.
I'm having an interesting problem implementing a global keyboard hook.
I wrote a dll which is used to set the hook and then an application (Delphi) which loads the dll and processes the results of the hook. This was done this afternoon on my PC at work and after some testing I figured it was working 100%.
I've just tested the same app and dll here at home and I'm not getting any errors, but the application does not appear to be getting any data either.
Both machines are WinXP, although my work machine is SP2 and this one is SP3.
Has there been some change in the Win32 API which would cause this to malfunction, or could the problem be related to some A/V / Spyware / MS Update that has been released recently?
I'm hoping somebody here will know of an obvious reason that this may happen before I spend hours debugging.
Thanks!
Actually some A/Vs don't like homemade hooks. I've got the same problem with my mouse hooker on some machines, and it doesn't depend on service pack version.
Yeah, I could. I haven't installed Delphi on this machine, but I think I might have to. I'm going for the low hanging fruit here. If there's an obvious answer, there's no need to go through all the trouble of debugging and hoping to find what might be the problem.
My first suspicion is that there's been a change in the API somewhere.
As I mentioned, this app works absolutely perfectly on my work machine.
Do you have a debugger on your home computer? Do you receive any messages via the hook at all?
Can it be that some other application is hooking, and don't pass the message on down the hook-chain?
BTW: I love virtual machines for this kind of testing. Keep a clean XP install. Install SP2, and test your application. Roll back to clean install again, and install SP3. Try your application again. This way you will know if its SP3, since there is nothing else to mess things up. I like to keep a set of snapshots around with different configurations.
Which kind of hook are you using? I once used the WH_CBT-type and encountered problems when certain other applications where running. One case I could trace back to Trillian, which seems to do also some kind of hooking (and maybe screws up).
Apart from that I am currently working on an application that uses the WH_KEYBOARD-hook and this works on SP2 and SP3 equally well. The MSDN also doesn't mention any service-pack related changes.
What you can do to trace the bug on your home machine:
make sure to check all result values of all system api calls (and use GetLastError in case of error)
provide some kind of debug output in case of error (e.g. as message box or to a text file)
optional: log some status messages so you know whats going on internally
One alternative is to use a low level keyboardhook. (Just a different param to SetWindowsHookEx). The hook is processed in the message loop of the registering thread, and thus does not need to inject a dll everywhere. And for some odd reason VirusScanners/Firewalls interfere much less with it. They often silently block dllinjection or normal keyboardhooks. Also removes the need to share the hHook across processes if you want it to work in older windows versions.
And if you abuse a keyboardhook to implement global hotkeys(Have seen that a lot) use RegisterHotkey/http://msdn.microsoft.com/en-us/library/ms646309.aspx) instead.