Run your app under Process Monitor with a set of filters, start it with the current directory pointed at a folder you control, and look for DLL loads that search that folder. Any load that looks in the current directory is a candidate for planting. Microsoft documents this procedure in its DLL security guidance.
Before you start
Use a test machine or virtual machine. Process Monitor is a Sysinternals tool and produces a lot of output, so the filters matter. This test checks your own application, whether it is a game, a launcher or an installer.
The steps
- Start Process Monitor.
- Add include filters: Operation is CreateFile, Operation is LoadImage, and Path contains each of .cpl, .dll, .drv, .exe, .ocx, .scr and .sys.
- Add exclude filters: Process Name is procmon.exe, Procmon64.exe or System; Operation begins with IRP_MJ_ or FASTIO_; Result is SUCCESS; Path ends with pagefile.sys.
- Start your application with the current directory set to a specific folder. Microsoft's example is double clicking a file whose extension is handled by your application.
- Read the output for suspicious paths, such as a DLL being requested from that current directory.
Per the Microsoft page, a call to the current directory to load a DLL may indicate a vulnerability.
Reading the results
The filter excludes SUCCESS results, so what remains are failed lookups. A failed lookup in a user writable folder is the interesting part: the program asked for a DLL there and did not find one. If an attacker had put one there, it would have loaded.
| What you see | What it suggests |
|---|---|
| NAME NOT FOUND for a DLL in the current directory | The app searches there; an attacker could plant a file |
| Lookups only in the install folder and system folders | Search order looks safe in this scenario |
| A bare name in a loader call in your source | Candidate to change to a full path |
Fixing what you find
Microsoft's recommendations include using fully qualified paths, using the LOAD_LIBRARY_SEARCH flags with LoadLibraryEx or SetDefaultDllDirectories, and removing the current directory from the search path with SetDllDirectory using an empty string early in startup. Because SetDllDirectory affects the entire process, test with any third party DLLs you load.
Make it routine
Add this check to the release checklist for every installer and launcher. Re-run it after you update an engine, a runtime or a major dependency, since those change what gets loaded.
Try it yourself
The scan demo shows a repeatable check turning into a report. Click through it and think about which checks in your release process are still manual.
Click through it at your own pace, or open it full screen.
Quick check
Do I need admin rights to run the test?
Process Monitor generally needs elevated rights to capture events. Use a test machine and follow your own policy.
Why exclude SUCCESS results?
Microsoft's filter set does, so the output focuses on lookups that failed, which is where a planted file would have been loaded instead.
Safeguard's code scanning and dependency scanning can run in your pipeline alongside manual checks like this one. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
