I can't say for sure, but I think you'll find that you have an over zealous system administrator who decided to deploy a security system that can only have been designed by chimps, then implemented by the most idiotic intern at Microsoft.
Go read this Knowledge Base article: http://support.microsoft.com/kb/2264107
Can you believe that? Some idiot thinks that DLLs are always completely self-contained, that no-one other than Microsoft might build an application where DLL1 depends on DLL2 which happens to be delivered as part of the same product.
This wouldn't be so bad if the numb nuts that actually implemented the security feature actually knew what they were doing. It appears that setting the CWDIllegalInDllSearch entry does not "omit the current directory from the search". Instead, it changes the order it considers directories. If a matching DLL is in the current directory, it halts the scan immediately. Doesn't check that the DLL would have been found via the official path strategy - it just stops.
Now, it's fine to say "but this is a vector for malware". Sure it is, but if someone can install a DLL into your application directory, then they can change your application as well, so this hack prevents *nothing*.
In case one of the afore-mentioned chimps is listening, they should find someone smarter than they are and ask what the letters in DLL mean. Dynamic Link Library. Suggesting that you can work around the problems this security setting causes by explicitly (and manually) loading the libraries you need with LoadLibrary() misses the point that there are no published APIs that tell you what libraries a specific DLL needs. If I have to write my app so that it analyses every DLL it loads, then every DLL that *they* load, recursing till I hit metal, then there is no point in actually *linking* against those libraries.