.DLL's produced by Webbroker on my XE8 have stopped working. Browsers get Error 500 regardless of server (Microsoft Server 2011 or Abyss Web Server). .Dll's produced two days ago work fine on both servers.
I installed XE10.1 (I put off the upgrade until now) and precisely the same problem occurs in the simplest of applications. Result.Content := '<p>Hello world</p>'; crashes.
I am at a loss and am wondering if my compiler's defines have been somehow tampered with. The last thing I did before things stopped working was to try out a IP*Works component and Windows did an update. Nothing else that I can think of.
Like some of you pointed out - many thanks. :-)
The problem had nothing to do with the compiler defines. Frankly, I don't quite understand what happened. It seems that Delphi 10 update 1 changed my .DPR file and inserted "Web.Win.ISAPIThreadPool"
Simultaneously, it seems, my test server reverted to an older version - heaven knows how that happened and the problem below manifested itself:
http://qc.embarcadero.com/wc/qcmain.aspx?d=129148
Thank you for helping me regain my sanity and I wish you all the best during this stressful season.
Related
Update: It turned out that there was something with installing Delphi 10.4 CE that broke my app (thanks, DelphiCoder!); specifically, it was something in the Windows Registry that was broken. After using ProcessMonitor to ensure no Delphi 10.4 (aka 21.0) was being invoked, I ended up cleaning out the registry of all 10.4 references, rebuilding completely (not clear if this was needed or not), and lo and behold, it works again! I'm adding this update in case someone in a similar situation finds this question - remember to back up your registry first and be careful!
Original Post: I created several DLLs with Matlab Compiler 10 years ago, with C wrappers, to make them available with Delphi. Once I got them working, they always worked - until today! The code in the C wrapper initialization function in question is in the code box below; the "Could not initialize library" is printed to the console when I run my Delphi app.
mclmcrInitialize();
if (!mclInitializeApplication(NULL, 0)) {
fprintf(stderr, "Could not initialize application\n");
}
if (!libMyDllInitialize()) {
fprintf(stderr, "Could not initialize library\n");
}
The problem is that this has never happened before, over all the probably 10 years since we first wrote these! My machine has the correct version of the 32-bit 2021a MCR installed, as it has for several years; I've installed this on numerous machines from Windows XP up to Windows 10, The DLLs were last built 5 - 7 years ago; anyway, I don't have access to the Matlab compiler anymore. The only thing that has changed is my app, but not anywhere near where this DLL initialization code is called; also, when the problem first happened, my app was working, then didn't -without any changes. Finally, I went back a few days and rebuilt my app, and it still fails.
So I am really stuck, and need some advanced help in debugging DLL startup issues on Windows. I tried looking in the Windows Event Logger, but nothing appears to show up there. Logs to check? A setting in the Registry that somehow got hosed? Wrong phase of the moon? How does one debug loading/initializing a formerly working DLL when forced to treat it as a black box? Help!
How does one debug loading/initializing a formerly working DLL [...]?
I think there is no definitive answer to your question.
This is how we have gone about debugging the loading/initializing of DLLs and applications and may help you:
We regularly work with systems where we have no source code for the DLLs (and often we don't have any source code for the applications either). We experience DLL conflicts quite regularly. When testing why applications don't start as expected we have found the use of Sysinternal's Process Monitor by Mark Russinovich invaluable.
This will show you system level activity. You can filter for your process and then you will see all file, registry, thread and network activity (although thread and network are quite limited). If the DLL has dependencies then the system tries to find those and so you will be able to discover all dependent DLLs and COM interfaces (by seeing the registry lookups for that interface) that it's looking for. Process Monitor will show if the resource is not found or if access is denied.
Slightly more difficult to discover is if one of the dependencies exists but the export table has changed (so the functions have different signatures or export ordinals). There are ways to check that (by looking at the export and import tables) but generally (if you have access to a working environment) it's enough to check the filesize, timestamp (and the VERSIONINFO resource if there is one) between DLLs.
Hello I just finally buy the newest Delphi after many years using older version or free pascal. Everything seem to work as expected except when I look the help I can't find winapi or opengl topics like i could in old version.
Do I need to install something special so I can press f1 over for example "messagebox" or "sleep" or "glcolor" or whatever because I install delphi xe7 3 times now but there is only "Install Help" option during install and no other help option I can see.
A while ago I had tried to fix this annoying change from how it was to limited success. What I had done was:
- install the documentation part of "Windows 7 SDK with .net 3.5" (won't work with any later SDK installs since they changed help format)
- install a program from helpware called FAR
- in program FAR, choose H2 UTILS, then select "embarcadero.rs_xe7", then click register
- go to plugins and add WIN7SDKCOM
That was it, with that done both the table of contents and index of delphi help contained the whole windows 7 documentation. HOWEVER! There was a problem, and it was that many (most?) winapi F1 context sensitive help didn't work, it still took me to the standard delphi help page that said to go to MSDN even though if i went to the index i would immediately find the topic.
So, imperfect answer that I'm relaying from memory since I reinstalled that computer and didn't add the win7sdk this time. Hopefully it helps, I know I was happy to have easier offline access to the documentation. Maybe someone can figure out the extra step to make F1 help also work completely.
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 recently installed the latest rounds of Windows updates, including the .NET 4.0 updates and the Visual Studio updates (but not VS2010 SP1). Since then, my F# compiler has been running really, really slow. I thought it might be this problem with crl.microsoft.com, but it turns out not to be. Also, I think mscorsvw.exe has completed running. (I forget the command to force it, but it doesn't kick in, even when the machine is idle.)
Also:
The F# compiler is producing correctly running code, just slowly.
The C# compiler remains as fast as always.
Has anyone else experienced this problem?
-Neil
I forgot to run ngen.exe. After running that, F# compiles are back to normal speed.
-Neil
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.