So I figure since even our resident Windows fanboys are throwing out problems here, I might as well too :-)

I'm not quite sure what to make of this particular one, and thankfully the problem will be resolved soon with the user in question getting a new machine soon. But I'm still curious to see if anyone else has seen similar, and what the fix was.

Problem: Windows appears to be ignoring the "Start in" setting of shortcuts. We have a system set up where unapproved versions of our product are synced into a folder, instead of over the existing approved binaries in the root folder of the product. Then a shortcut exists to run the binary from the unapproved folder, and start in is pointed at the product root folder. This works fine for nearly everyone, but on this one system, it complains about not finding DLLs needed to run. The DLL in question is in the root folder, and moving it to the unapproved folder allows it to work. The particular DLL is not a windows DLL, so it's not conflicting in a weird way.

To clarify, here is the setup:

The unapproved binary is here:
c:\Product\unapproved\product.exe

Then DLLs are here:
c:\Product\required.dll

And the shortcut is to C:\Product\unapproved\product.exe, with Start in set to C:\product\.

I've stopped the anti virus to eliminate it from interfering, and the problem persisted. I tried replicating the setup with other executables, by moving one into a different folder, making a shortcut, and ended up with the same behavior where the executable wouldn't run. So it's not specific to our product either.

Any ideas?

Certain versions of Windows ignore (by default) the current directory when they're looking for DLLs. This is a security enhancement. The behaviour changed in (IIRC) Windows XP SP1 / Windows 2003.

That doesn't appear to be the problem here. Numerous other machines with XP SP3, and Windows 7 work fine with the same setup. Checking the registry, SafeDllSearchMode appears to be unset on both a working box, and the broken one in question.

*sigh*. Seeing this same behavior on a few more systems, but we can't find anything in common to isolate the issue.

How do Windows IT people remain sane with this house of cards?

Check for variations in the configuration between the systems that work and the systems that don't.

Specifically, check to see if it's the UAC setting, or something related to the user account that's logged in when the problem occurs.

Let me be more specific. When I have UAC turned off, any command prompt or shell command that I open (a.) will be an elevated command prompt, and (b.) will respect the "START IN" location. The shell will execute with the desired folder as the current directory.

When I have UAC turned on, any command prompt or shell command that I execute, by default, will not be elevated. If I need to elevate it, I can, but in doing so, it stops respecting the "START IN" location and starts in C:\windows\system32.

In other words, if I leave it unelevated, the folder is correct but the command doesn't have the permissions it needs to accomplish the task, but if I elevate it, then it gets the permissions, but it's in the wrong folder.

If the thing I'm running is a batch file, I can fix this by adding this to the top of the batch file:
setlocal enableextensions
cd /d "%~dp0"

I've got no idea how the above works, but it does seem to work. I found it on the web after some searches. I don't know far back in windows versions it'll work. I know it works on Win7 and Vista but I'm not sure about XP for example.

Forgot to mention, this is only on Windows XP (as we don't have any wide deployments of Vista or 7 here). So UAC isn't mucking with things at least.

As for cd /d "%~dp0", that is:

/d allows changing to another drive
%0 would normally be the filename of the script running
~dp before the 0 adds in the full path with drive letter.

Interesting. Well, still see if it's got something to do with the user context in which the problem occurs. I'm sure XP has some quirks in that area too.

How is the shortcut being invoked? GUI double-click or something else? Can you determine if it fails for all users on that computer or just one?

Could it be some odd %PATH% issue? Or can you add the .dll directory to the path?

-jk