I’m working with the Windows SearchPath function and running into an issue. When I pass NULL as the first parameter to use the default search path, it always checks the c:\windows folder first.
Here’s my situation: I have an old config file sitting in c:\windows that I need to keep there for backwards compatibility. But I want my program to use a newer version of the same config file that I placed in c:\users\public instead.
I already added c:\users\public to the beginning of my system PATH environment variable. However, when SearchPath runs with NULL for the path parameter, it still picks up the file from c:\windows rather than c:\users\public.
The weird part is that if I temporarily remove the file from c:\windows, then SearchPath correctly finds my file in c:\users\public. This proves my PATH setup is working.
Is there any way to make SearchPath skip the c:\windows directory without changing the calling code? I can’t modify the caller to pass a specific path instead of NULL.
yeah, super frustrating! searchpath def goes for c:\windows first and there’s no way to change that. maybe try dll injection, but it’s a pain to set up. finding another workaround might be the best bet here.
Oof, tricky but doable. You can’t change searchpath’s hardcoded behavior, but here’s what worked for me - use file system redirection with app compatibility shims. Create a custom shim database that redirects file access from c:\windows to your public folder. More setup than symlinks, but you don’t need to touch either file location.
Been there. SearchPath always checks c:\windows first and you can’t change that.
Don’t fight the API - work around it. Set up monitoring for both locations and automate which version gets priority.
Here’s my approach: create automation that watches your newer config in c:\users\public for changes. When it updates, temporarily rename the old c:\windows file (add .backup or whatever), so SearchPath grabs your newer version.
Restore the original filename when you need compatibility. Your calling code stays untouched and both files remain where they belong.
I’ve fixed similar precedence issues this way - works great. File monitoring automation is easy to build without coding.
There’s no direct way to exclude the c:\windows directory from the SearchPath API. It’s hardcoded to check there first, regardless of your PATH settings. I faced a similar issue and found a few workarounds: you can create a wrapper DLL to intercept SearchPath calls, or use the Application Compatibility Toolkit to redirect file access. If modifying the old config file is an option, renaming it could be the cleanest solution to avoid conflicts. This way, you keep the file for compatibility but prevent SearchPath from using it.
Had this exact problem three years back during a legacy migration. You can’t change that c:\windows priority in SearchPath - Microsoft locked it down for security and there’s no workaround. What saved me was NTFS hard links instead of symlinks. I created a hard link in c:\windows that points to my actual config file in c:\users\public. When I update the file in public, it instantly shows up in the windows directory since they’re the same physical file. Hard links beat symlinks here because older apps handle them better and you don’t need admin rights to create them most of the time. SearchPath gets its c:\windows file, you keep your config wherever it makes sense. Running this in production for years with zero issues.
SearchPath is designed to work this way - you can’t change it through configuration. But I solved the exact same problem using symbolic links. Instead of fighting the API’s search order, I just created a junction point in c:\windows that redirects to where I actually want the file. The API thinks it’s finding the original file, but it’s actually hitting my newer config in c:\users\public. No code changes needed, and everything stays backwards compatible. Your old code keeps working, and you can update the config file in the public directory like normal. I’ve run this in production for two years with zero problems.
Hit this exact wall myself a few years back. The API behavior is baked in and you can’t override it.
But here’s what worked - instead of fighting the search order, I flipped it around. Moved my newer config file INTO c:\windows and dropped a symbolic link in c:\users\public that points back to it.
SearchPath finds what it thinks is the “old” file in c:\windows, but it’s actually your newer version. The symlink in public keeps up appearances for any other tools expecting the file there.
Ran this setup for about 18 months in a legacy system with zero issues. Backwards compatibility stays intact, your newer config gets used, and you don’t need file monitoring or renaming tricks that could break under load.
