Hi Stuart, reflecting on your reply referencing Raymond Chen.

Relative or Explicit Path

You can decide relative or specific path for each file your app references in code. That is your decision, 100%!
PB will do as you ask it when you call functions like FileOpen(...) , Run(...), or SaveAs(...).

PowerBuilder supports both relative and explicit file path in each app's library list. Again, your decision for each app file.

Relative Paths for PB Runtime Files

PB apps rely on PB runtime files (like PBVM190.dll, PBDWE190.dll, and PBODB190.ini).
They are referenced by relative path. Standard Windows file resolution process is you "weapon of choice" to customize and lock down app's file search. Several options come to mind (combine as you like)

• Locate all runtime files required by your app in your app's "app folder"
• Specify App Path for your particular app
• Lock down access to your app folder as much as possible
• Don't forget the "all files matter" view: Include graphics files, help files, document templates, etc.
• Follow same security guidelines as with any other Windows app being PB or non-PB.

As Raymond Chen points out in that blog post: You have a whole different issue than some app being vulnerable if an attacker already gained system admin privilege to your system.

Your security vulnerability is a fallacy I believe.

Raymond Chen explains this rather well  ;

https://devblogs.microsoft.com/oldnewthing/20130705-00/?p=3883

If you want to restrict any Windows application's search path you can definer App Paths per app via registry.
See Microsoft docs for details.

PowerBuilder virtual machine doesn't scan all folders for all files. It uses DLL files just like any other large Windows app.  Including standard file resolution via path, app paths, GAC (for .NET assemblies), etc.

Appeon signs PB runtime files and apply additional security features to protect the integrity of each file.
Example:

You should apply same security approach to PowerBuilder apps as you do to other Windows apps. On top of my head I can't remember a single app running on Windows that doesn't include DLL files itself and/or call standard Windows APIs which all delivered via DLL files.

If an attacker injects a compromized version of Kernel32.exe in your system path it will impact every single app using the system path for file resolution - including Windows O/S itself.

HTH /Michael

Which DLL files does it appear to be looking for?

What tool are you using to track the behavior?

Hi Suhas;

  The PB run-time does not perform such exhaustive DLL searching. My guess is that something else is going on that is invoking this exhaustive O/S search. If a PB run-time DLL is not located via the local folder or System Path, the PB Loader stops and returns an instantiation error.

Regards ... Chris

Hi,

Which DLL's is it looking for?

Could it be you need to install C++ runtime or some other DLL's which are required like "atl100.dll"?

I think that if the files which are being looked for are in the PATH environment variable, windows wouldn't have to search all over the disk? Not 100% sure, as windows has a somewhat weird logic when looking for files (current path, GAC, PATH, etc.)

About protection: normally a good antivirus would intercept any malicious DLL's no matter where they are being found.

regards,

MiguelL