Problem with fbclient.dll

[Tomasz Dubiel]

Hello.

What can be the reason that Delphi exe using fbclient.dll for FB 3.0 (3.0.11 and older) uses msvcr100.dll from a local folder when exe is installed, but it doesn't use msvcp100.dll from this folder, but msvcp_win.dll from SYSWOW64? We changed the file name even to msvcp_win.dll, but still the file from SYSWOW64 is used.

Best regards,

Tomasz.

[Tomasz Tyrakowski]

64-bit DLL where 32-bit one is required?

regards
Tomasz

[Tomasz Dubiel]

I don't quite understand. exe is 32bit, I copied the file from SYSWOW64 to a local folder, but still the file from SYSWOW64 is used. It causes problems on some PCs as other versions of this dll is installed and one feature doesnt work then.

[Tomasz Dubiel]

I copied this file from System32 to a local folder, but still no changes. The file from SYSWOW64 is loaded.

[Tomasz Tyrakowski]

On 29.09.2023 at 09:28, Tomasz Dubiel wrote:
> I don't quite understand. exe is 32bit, I copied the file from SYSWOW64 to
> a local folder, but still the file from SYSWOW64 is used. It causes
> problems on some PCs as other versions of this dll is installed and one
> feature doesnt work then.

What I meant was that msvcr100.dll in the app folder is 32-bit, but
msvcp100.dll is 64-bit, so it's omitted and Windows looks for a 32-bit
one in its default locations (SYSWOW64 is a default directory for 32-bit
dlls on 64-bit Windows).
As to why it persists on loading the dll from the system location even
when the dll is copied locally, I'm at a loss. Perhaps the dll is
already loaded by another process and Windows just maps it into your
process' memory instead of loading it anew from disk, but that's just a
hypothesis.
Maybe someone with a more deep understanding of the internals of Windows
dll loading will help.

regards
Tomasz

[Tomasz Dubiel]

I checked and msvcp100.dll used locally is 32-bit so this should be loaded by fbclient.dll, right? Can there be any problems with a concrete version of this file so that it can be read by fbclient.dll?

Best regards.

[Tomasz Tyrakowski]

On 29.09.2023 at 09:56, Tomasz Dubiel wrote:
> I checked and msvcp100.dll used locally is 32-bit so this should be loaded
> by fbclient.dll, right? Can there be any problems with a concrete version
> of this file so that it can be read by fbclient.dll?

Maybe download the FB server 32-bit zip package and take fbclient and
msvc* dlls from the zip distribution? They should be compatible with
each other.

regards
Tomasz

[Tomasz Dubiel]

I have tried this now and restarted PC to be sure. Still msvcp_win.dll is loaded from SYSWOW64.

Best regards.

[Tomasz Dubiel]

Can be this simply fbclient.dll bug? The same issue is with IBExpert.

[Tomasz Tyrakowski]

On 29.09.2023 at 10:39, Tomasz Dubiel wrote:
> Can be this simply fbclient.dll bug? The same issue is with IBExpert.

Rather unlikely. While it's possible to load a DLL from a specific
location, you'd have to use WinAPI functions (LoadLibrary,
GetProcAddress, etc.) by hand (load the DLL and resolve each function
you're going to call). When you just link your code against a DLL (like
fbclient is linked against msvc*), you don't specify the exact location
of the DLL in the target system - Windows should determine which DLL
file to load. The problem is, that AFAIK the DLL from the local
directory takes precedence over searching PATH directories, which is
clearly not the case in your scenario.

regards
Tomasz

[Tomasz Dubiel]

Doesn't it happen in your environment? 32bit Delphi exe using fbclient.dll 3.0.11 - can you check what dlls are used by your exe (using for example ProcessExplorer)?

Best regards.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 29.09.2023 10:39:
> Can be this simply fbclient.dll bug?

No, this is the way Windows works:

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

MSVC RT redistributable libraries aside of fbclient.dll are provided as a
fallback. They must not be used if needed CRT already present in system.

--
WBR, SD.

[Tomasz Dubiel]

msvcr100.dll is somehow used from a local folder.

OK, but how can we fix that? We can't force users to change dlls in SYSWOW64 folder. We thought that placing all dlls in a local folder will make fbclient.dll to use them. However, that only applies to msvcr100.dll

Best regards.

[Tomasz Dubiel]

For some users there is a wrong version of this file in SYSWOW64 and when showing attachments from MON$ATTACHMENTS, delphi returns error that it expects integer, but gets longint (change from FB 2.5 to 3.0 for MON$ATTACHMENT_ID)

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 29.09.2023 11:01:
> OK, but how can we fix that? We can't force users to change dlls in SYSWOW64
> folder. We thought that placing all dlls in a local folder will make
> fbclient.dll to use them. However, that only applies to msvcr100.dll

Most likely you missed some dependencies and because of that local
msvcp100.dll cannot be loaded.
Perhaps this library depends on some UCRT assembly that are not installed on
this particular computer. Make sure that Windows Update keeps it fresh.
The solution is NOT place DLL in application folder but add CRT into system
requirements so it has to be installed properly from proper MS installer in
order to make your application run.

> For some users there is a wrong version of this file in SYSWOW64 and when showing attachments from MON$ATTACHMENTS, delphi returns error that it expects integer, but gets longint (change from FB 2.5 to 3.0 for MON$ATTACHMENT_ID)

This is not related to C++ Runtime in any way.

--
WBR, SD.

[Tomasz Tyrakowski]

On 29.09.2023 at 10:55, Tomasz Dubiel wrote:
> Doesn't it happen in your environment? 32bit Delphi exe using fbclient.dll
> 3.0.11 - can you check what dlls are used by your exe (using for example
> ProcessExplorer)?

Just checked. With 3.0.11 fbclient it's exactly as in your case
(msvcr100.dll from the app folder, msvcp100.dll not loaded, instead
loaded msvcp_win.dll from SysWOW64).
With 2.5.9 client, none of msvcp80.dll, msvcr80.dll got loaded from the
app folder. Instead, the process loaded msvcp_win.dll from SysWOW64 and
msvcr80.dll from WinSxS/very_long_foler_name_here/.
With 4.0.2 client, msvcp140.dll got loaded from the app folder, but
msvcp_win.dll from SysWOW64 was loaded as well. vcruntime140.dll from
app folder was not loaded, instead msvcrt.dll from SysWOW64 was.
So it seems it depends on which VC runtimes have been previously
installed in the target system (the link provided by Dimitry explains
much - the app current dir is way down on the 7th place). Mine is
probably pretty littered (Visual Studio, Embarcadero, a couple of
different compilers and interpreters, and a lot of other software, each
of which might have installed the vc runtime in one version or another).

regards
Tomasz

[Tomasz Dubiel]

I think this is related, because:

such error occurs in one of our customer's environment. I set up the environment and connection to this customer, I have the same program installation, the same files and I don't have such error.

What can be different than using other dlls from Windows locations?

Best regards.

[Tomasz Tyrakowski]

On 29.09.2023 at 11:23, Tomasz Dubiel wrote:
> I think this is related, because:
> such error occurs in one of our customer's environment. I set up the
> environment and connection to this customer, I have the same program
> installation, the same files and I don't have such error.
> What can be different than using other dlls from Windows locations?
> Best regards.

Is it possible that the customer's machine has a different fbclient
installed in a system location, and it gets loaded instead of yours?

regards
Tomasz

[Tomasz Dubiel]

That's not that, as well. ProcessExplorer shows that fbclient.dll is taken from a local folder and I use the same.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 29.09.2023 12:11:
> ProcessExplorer shows that fbclient.dll is taken from a local folder and I use
> the same.

Can you use ProcessMonitor to watch loading process in details? It could show
why the library was not loaded.

--
WBR, SD.

[Tomasz Dubiel]

Yeah, I usually forget about that tool.

Well, with the string msvcp, I can only see one entry with success loading image C:\Windows\SysWOW64\msvcp_win.dll

I see no entry of even trying loading msvcp100.dll (however there is a lot of output, maybe I should try searching for other text)

Weird - that's still doesnt sound as some bug?

Best regards.

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 29.09.2023 12:22:
> I see no entry of even trying loading msvcp100.dll (however there is a lot of output, maybe I should try searching for other text)

The only filter you need is by name of your application. Then read whole
output sequentially. Remember "known DLLs" and "already loaded DLLs" that has
priority over everything other.

> Weird - that's still doesnt sound as some bug?

Definitely. It looks like an usual Windows DLL mess.

--
WBR, SD.

[Tomasz Dubiel]

I've done it. I filtered only output of my exe, but still there is a lot of it.

[Tomasz Dubiel]

But there is no entry of even trying to load msvcp100.dll, only msvcp_win.dll. Could someone look at the code of fbclient.dll? It looks like it's not dependent on mscp100.dll, but msvcp_win.dll.

piątek, 29 września 2023 o 12:26:28 UTC+2 sd napisał(a):

[Dimitry Sibiryakov]

Tomasz Dubiel wrote 29.09.2023 12:34:
> Could someone look at the code of fbclient.dll?

It is not in code: dependency are handled by linker. You can look at the
import table yourself.

--
WBR, SD.

[Tomasz Tyrakowski]

On 29.09.2023 at 12:35, 'Dimitry Sibiryakov' via firebird-support wrote:
>> Could someone look at the code of fbclient.dll?
>
>   It is not in code: dependency are handled by linker. You can look at
> the import table yourself.
>

It may not be enough. If the DLL from the dependencies has its own
dependencies, they're not explicitly listed in the import table of the
first DLL.
PEInfo for 32-bit fbclient.dll (3.0.11) doesn't show msvcp100.dll (it
shows: kernel32.dll, advapi32.dll, shell32.dll, ws2_32.dll,
msvcr100.dll, mpr.dll, user32.dll and ole32.dll).

regards
Tomasz (the other one ;) )

[Dimitry Sibiryakov]

Tomasz Tyrakowski wrote 29.09.2023 12:51:
> It may not be enough. If the DLL from the dependencies has its own dependencies,
> they're not explicitly listed in the import table of the first DLL.

Yes. That's what Dependency Walker is for.

> PEInfo for 32-bit fbclient.dll (3.0.11) doesn't show msvcp100.dll (it shows: kernel32.dll, advapi32.dll, shell32.dll, ws2_32.dll, msvcr100.dll, mpr.dll, user32.dll and ole32.dll).

And this is the answer why it is not loaded.

--
WBR, SD.

[Tomasz Dubiel]

But https://firebirdsql.org/file/documentation/html/en/firebirddocs/qsg3/firebird-3-quickstartguide.html

shows:

32-bit library versions for use with 64-bit Firebird

fbclient.dll, msvcp100.dll, msvcr100.dll

So it looks something is wrong?

Best regards.

[Tomasz Tyrakowski]

On 29.09.2023 at 12:54, 'Dimitry Sibiryakov' via firebird-support wrote:
>> It may not be enough. If the DLL from the dependencies has its own
>> dependencies, they're not explicitly listed in the import table of the
>> first DLL.
>
>   Yes. That's what Dependency Walker is for.

It can only walk over DLLs from the system you're running it at. It has
no way of knowing which actual DLL will be loaded on the target machine
and what its dependencies might be.
However, since Tomasz said he could run procmon on the target machine,
dependency walking is definitely an option here.
Can you recommend a good walker? I use PEInfo, but it requires clicking
each dependency one by one to see its dependencies (then click on those,
etc.). Do you happen to know about a tool which would display a tree or
some other combined data from all DLLs?

regards
Tomasz

[Tomasz Dubiel]

Copying all those files locally changes nothing.

[Dimitry Sibiryakov]

Tomasz Tyrakowski wrote 29.09.2023 13:04:
> Can you recommend a good walker? I use PEInfo, but it requires clicking each
> dependency one by one to see its dependencies (then click on those, etc.). Do
> you happen to know about a tool which would display a tree or some other
> combined data from all DLLs?

How about this one? https://www.dependencywalker.com

--
WBR, SD.

[Mark Rotteveel]

On 29-09-2023 11:04, Tomasz Dubiel wrote:
> For some users there is a wrong version of this file in SYSWOW64 and
> when showing attachments from MON$ATTACHMENTS, delphi returns error that
> it expects integer, but gets longint (change from FB 2.5 to 3.0 for
> MON$ATTACHMENT_ID)

I don't see what this would have to do with the wrong MS Visual C/C++
DLL getting loaded. This sounds more like a component expecting a 32-bit
integer, and throwing an error because it now receives a 64-bit integer
instead.

Mark
--
Mark Rotteveel

[Tomasz Dubiel]

OK, but what else could cause such error? I have the environment and connection to the customer, I have the same installation and files and I dont have such error so what else apart from different dll from Windows locations could cause such problems?

Best regards.

[Tomasz Tyrakowski]

On 29.09.2023 at 13:26, 'Dimitry Sibiryakov' via firebird-support wrote:
>> Can you recommend a good walker? [...]

>
>   How about this one? https://www.dependencywalker.com

Looks promising. However, I downloaded the 2.2 version (both x86 and
x64), pointed them at fbclient.dll and they both hang up with a
hourglass cursor and no response ;)

Tomasz

[Tomasz Dubiel]

The same for me.

[Tomasz Tyrakowski]

>> hourglass cursor and no response 😉

You can try this one:

https://www.pazera-software.com/products/peinfo/

but you have to click each DLL in imports to open it and see its
imports, etc., so it's cumbersome, but in lack of better options...

regards
Tomasz

[Tomasz Dubiel]

You're right. Even with the other dll I still don't get the error.

[Vlad Khorsun]

  All,

fbclient.dll doesn't load explicitly any msvcXXX.dll, as it was pointed out already - they are loaded by OS loader.

msvcpXXX is used by ICU libraries. For example msvcp100.dll is used by icuin52.dll (speaking about FB3).

I never saw msvcp_win.dll, I can't find mention of it on MS sites. Anyway, I found it on my computer and it's export 

table contains mostly C++ entrypoints that we never ever used in any part of Firebird.

As for tool for view dependencies, I use this one: https://github.com/lucasg/Dependencies

Regards,

Vlad

PS I found that msvcp_win.dll is linked with shell32.dll, which is linked with fbclient.dll.

Perhaps there is more indirect dependencies.