0

I have an application builded with Run-time Packages. When the executable starts it auto loads the required packages (.bpl).

Recently we has installed an Windows 2008 R2 server to use as Terminal Services.

We maintain some old compiled versions of our application in different paths, like this:

c:\app\version_1\common.bpl
c:\app\version_1\app.exe

c:\app\version_2\common.bpl
c:\app\version_2\app.exe

Common.bpl is the a run-time package what app.exe depends on.

THE PROBLEM:

I start "c:\app\version_2\app.exe" and it loads "c:\app\version_2\common.bpl". When I start the "c:\app\version_1\app.exe" it loads the WRONG bpl (from version_2).

The path "c:\app\version_2\" isn't at the system search path.

At Windows2003 server this problem doesn't occurs.

What can I do to solve this?

Thanks!

I have downloaded the Process Explorer (microsoft sysinternals), and checked the loaded modules of each executable, all they are correct!

But I noticed another problem. After start the second version, an entry-not-found-error occurs, telling me what a initialization entry point, of an unit what only exists in one of the versions, could not be found.

Something is very strange. The ProcessExplorer is telling me that the process is loading the correct modoles, but when they are running this seems not be happening.

Seems the applications are sharing the loaded modules.

SOLVED

There was a MouseHook using FindVCLWindow, this was generating the AV.

Sorry about inconvenience guys, and thanks!

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
Beto Neto
  • 3,962
  • 7
  • 47
  • 81
  • hard to imagine how a file in the same folder as executable is over looked – David Heffernan Oct 10 '12 at 21:13
  • 1
    Are you sure it's not another file-virtualization feature in Windows Terminal Services taking over? In other word, what you think is happening is not what's happening. To be sure, DELETE the BPL from version_2 and see if it's STILL wrong. If so then you have another cached/virtualized copy of that DLL somewhere in some OTHER directory in your path. – Warren P Oct 10 '12 at 21:54
  • @David - that is poor yet standard choice for Windows, when u not specifying full DLL pathname. Just like Excel can't open same-named files from different folders – Arioch 'The Oct 11 '12 at 07:06
  • @Arioch It's completely different. Excel's limitarion is just poor app design. Nothing to do with relative paths. Windows DLL search path has exe directory at the top of the list of places searched. That is excellent design. It allows for isolation and gives developers control. – David Heffernan Oct 11 '12 at 07:30
  • @WarrenP, might be correct here. just a guess... also have you embedded UAC manifest in your EXE files to avoid visualization? – kobik Oct 11 '12 at 08:30
  • I down't have UAC manisfest embedded. How can I do this?! I'm using Delphi 7. – Beto Neto Oct 11 '12 at 12:57
  • 1
    Create a manifest resource. Use the web to work out what it should contain. Compile it with brcc32. And link it with $R. – David Heffernan Oct 11 '12 at 14:31
  • 1
    I think what you need to do to avoid the virtualization is a PE-flag. Check this link: http://stackoverflow.com/questions/10517022/delphi-applications-and-the-tsaware-header-flag – Warren P Oct 11 '12 at 16:00
  • I vote to close this Q. I think you should simply delete it. – kobik Oct 17 '12 at 11:01

1 Answers1

2

If the BPLs are statically linked into the EXEs, and if the version_2 BPL is already in memory when the version_1 EXE is run, Windows will re-use the existing BPL in memory, it will not re-load a new copy of the other BPL. This is documented behavior:

If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.

When using static linking, there is no path information, so the OS loader has to go off of the file names by themselves.

To do what you are attempting, you need to create a .local file for each EXE to isolate them from each other so they can load their respective DLLs in parallel.

DLL/COM Redirection on Windows

Dynamic-Link Library Redirection

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 1
    You've got this all wrong. There are two distinct processes here. The MSDN link is referring to modules loaded in the calling process. Processes are isolated. The modules loaded by one process cannot influence which modules are loaded by another process. Imagine the havoc if that was true. I create a module called user32.dll with no exports and then load it into my process. Now, what happens when the next process starts? – David Heffernan Oct 11 '12 at 06:25
  • @David `LoadModule` is irrelevant here, true. That is PE Loader behaviour to save virtual memory by not copying pages if possible but sharing them. It was used for DLL Injection. There is little info on PE loader, some articles in some ancient blogs and such. But similar behavior was seen before. I wonder if he can include specially crafted manifest and use WinSxS to resolve that... – Arioch 'The Oct 11 '12 at 07:12
  • @Arioch I've no idea what you are talking about. None. I didn't talk about LoadModule and don't even know what that is. – David Heffernan Oct 11 '12 at 07:28
  • @Arioch'The Are you referring to the 16 bit `LoadModule` API? – David Heffernan Oct 11 '12 at 08:10
  • i misnamed `LoadLibrary`. I remember that same-name DLL already loaded at least *was* a trouble with static DLL linking, though i don;'t remember details now – Arioch 'The Oct 11 '12 at 08:25
  • @Arioch'The That was the case in the 16 bit days. But it was all fixed with 32 bit Windows. – David Heffernan Oct 11 '12 at 08:45
  • See [Dynamic-Link Library Search Order](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx). One thing to check would be if `common.bpl` is registered as a **KnownDLL** in the Registry. That could cause multiple apps in different folders to load the same physical file. – Remy Lebeau Oct 11 '12 at 19:17
  • I wonder why you don't remove the content that is clearly wrong. – David Heffernan Oct 11 '12 at 20:50