Any guesses as to why this simple test code would show WinHttpConnect fails with error code 6 (invalid handle or ERROR_INVALID_HANDLE):
HINTERNET internet = WinHttpOpen(L"test",WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,WINHTTP_NO_PROXY_NAME,WINHTTP_NO_PROXY_BYPASS,0);
assert(internet == (HINTERNET)1);
HINTERNET connect = WinHttpConnect(internet,L"www.microsoft.com",INTERNET_DEFAULT_HTTP_PORT,0);
assert(!connect);
DWORD err = GetLastError();
assert(err == 6);
All of the above asserts pass. I've run this code on my Win8 PC and also on a Win2003 server. Two different PCs, same issue. My original code was more complex and runs as a service, but I reduced down to this code and just ran it in a simple test app in user mode (not service).
My app is compiled with an older compiler, Borland Builder 6, but not sure that should be a problem.
I had already typed up my question and then figured this out just before I posted it. Instead of deleting or not posting my question, I figured I should share this because I know others are still stuck using this really old compiler also :(
C++ Borland Builder 6 does not include a WinHTTP.LIB file, so I used implib to create one, the same way I always do. Well, in this case it appears you need to use the -f flag to force it to import by name instead of ordinal, otherwise you get strange results.
implib -f winhttp.lib winhttp.dll
This worked for me anyway, and now my above code works on Win2003 server and also Win8 PC.
Sorry, I'm not sure where I got the WinHTTP.h file, probably from a newer version of a Borland/Inspire compiler, since the Microsoft SDK ones usually don't work.
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.
.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.
I have done all the searching and can't find a solution to this weird problem that's been bugging me for about 5 hours. I started this app in Lazarus, but then took it across to D5pro to see if I could solve the problem. Thought it might have been a Lazarus "thing."
In D5, I have an app fully-working (so far so good) and I decided to try some different approaches to the look and feel so I "Save Project As" into a new folder. I then went through all of the included Units and saved them to the new Folder. I copied the two OpenSSL .DLL to the new folder. Did a compile and run and it all works fine. Well, almost.
When I tried the new app, the POP3 Unit crashes at "Login"
I have stepped through and all of the basic login stuff, Server, Name, SSL parameters etc is identical to the former version.
I went back to the original app and did a full Build and it still worked fine. I did a full Build on the new app and it still crashes at Login.
It gets through the pop3.Sock.SSLDoConnect() OK, but comes back from pop3.Login() with an error 10061 which according to the BlckSock Synapse-Unit, means "Connection refused."
When it returns from this call Result:=ssConnect(s, #name, SizeOfVarSin(name)); which I assume is in the .DLL it has a Result of -1 which then triggers the GetLastError and that is "10061 - Connection refused"
As far as I can find, everything is identical between the two projects. All Library Paths are in the Environment and not within the project.
Any thoughts and suggestions?
There is not much to work with. Can you see all parameters in the debugger on the various external call moments?
A change of compiler of course can make hidden bugs come to the surface, just like e.g. optimization. A well known difference is that the life time of temps might vary (see here).
Probably you need to nail the defining difference first. As with Delphi, the debugger is your friend here.
OK, problem solved.
Sir Rufo, it was a good idea but it did not help, but thanks for trying.
I had copied the ssleay32.dll into the new app folder BEFORE I started compiling. It did not work. I did a full Build and it still did not work.
I decided to delete the ssleay32.dll and libeay32.dll and do a full Build. I ran it and of course it crashed, but this time I expected that.
I then copied the two .ddl back into the new app folder and did another full Build.
Bingo problem solved. Seems weird but it is working with both Lazarus and D5. Something to do with the way the .dll gets linked into compiled .dcu.
Doing the Build with no .dll available cleared that. Dropping the .dll back into the Folder and another Build got the .dll linking correctly included into the .dcu.
Aaarrggghhhhh :)
Is it technically possible (I don't think this would be restricted), and how do you go about it?
I got my little test app building fine, but when I run it I get a failure dialog.
The debug output is slightly more informative:
The thread 0xe4c has exited with code -1073741515 (0xc0000135).
The program '[3400] OpenCVTest2.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Then I created a Win8 Desktop app, which also built fine but failed to run.
MSVP100D.dll is part of the VC++ 2010 Redistributable which is not compatible with Win8. (Being a hacker I tried it anyway, the installer runs to completion - but the bits aren't installed.)
Is there a compiler flag I can try? Possibly a custom build of OpenCV would fix it, but that would be a last resort, and it might only fix the desktop app.
This guy shows an example of using OpenCV library for performing face detection in a Windows 8 Store app written using C++/CX:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV322
Also, at the below post he also describes how the C++ Runtime works for Windows 8Store apps:
http://blogs.msdn.com/b/vcblog/archive/2012/09/28/10354327.aspx
MSVP100D is not a part of VC10 redist. Note the "D" at the end of its name. That package only includes release builds. Your release builds should work fine. But mixing libraries from different VC versions might get you in trouble. See this. Your best chance is to build from source with VC11.
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.