views:

53

answers:

1

Hi! I'm having some 64-bit issues. Here's the scoop:

I have 32-bit COM exe (written in FoxPro). This exe invokes a 32-bit COM dll (also written in FoxPro). In the 32-bit Windows world, the dll is placed in C:/Windows/System32 directory, registered with C:/Windows/System32/regsvr32.exe and all is well. The exe can be launched and any processes that require the dll are fine.

It's a different story in the 64-bit world. I tried to install this application on a machine running Windows 7 x64 like so:

  • I place the dll in C:/Windows/SysWOW64
  • I register it with C:/Windows/SysWow64/regsvr32.exe, but I was only able to get the registration to succeed by running regsvr32 using the "Run As Administrator" context menu option.

Now when I try to run my exe, it is unable to invoke the dll except when my exe is launched using the "Run As Administrator" option. This is not good. A user shouldn't be required to be an admin just to run a simple app.

Does anybody know how I can get this to work without requiring the "Run As Administrator" option??

Thank you!

-Ken

+3  A: 

Old stuff, it probably was never tried on a user account with limited privileges before. It probably does something verboten, like writing to registry keys in HKLM\Software or creating a file in c:\windows. That's over and done with these days.

If you have no idea what it might be done then use SysInternals' ProcMon tool to observe it using the disk and the registry. The access denied error should pop out, although it takes a bit of digging. If you can't change the code then you really ought to consider to end-of-life this component. You can hack the rights for the specific file or registry key that it is trying to munch as an intermediary solution. Be sure not to do anything to the c:\windows directories, that causes more trouble than it solves. Which is another thing, your component really doesn't belong in a private Windows directory.

Hans Passant
+1. ProcMon is the only reliable way to find out why exactly that stuff wouldn't work.
sharptooth
+1. Thanks, Hans! I was able to track down the problem using ProcMon. Long story short, the DLL was trying to create and access a file in the SysWow64 directory with write privilages, something that only an Administrator can do. Corrected the problem and I'm good now!-Ken
Ken