32 bit compiled windows service on 64bit machine

  • Thread starter Thread starter heck0045
  • Start date Start date
H

heck0045

I have a windows service running on a 64bit windows server 2003 machine. I
have the exe compiled with the x86 targeted. As long as I leave the account
as LocalSystem, the app will run in 32 bit mode and I will see the *86 in the
task manager next to its name. BUT, if I change the account to run under any
other Active Directory account, it looses the *86 and runs natively as a 64
bit app. I wouldn't care, except that I have a 32bit com component that the
service uses and therefore it must run as a 32bit process....AND the service
needs access to a network fileshare, so it cannot run as LocalSystem. I'm
stuck! Any help?

How can I allow a windows service to continue running under 32 bit AND use
an AD account for its security context?

Has anyone else seen this? Is there any way to fix it?
 
Well that's an interesting one, and tbh I'm surprised it switches to running
as a 64bit process if you've specifically set the compiler output target as
x86.

If I had to make a wild guess, I'd say maybe it runs as a separate process
when you run it under LocalSystem (and therefore is loaded correctly as a
32bit app) but when you run it under a specific user account its loaded
within "services.exe" and thus magically becomes a 64bit app. This doesn't
even sound reasonable to me now that I've read what I just wrote, and I
suspect it needs further investigation!

As a potential solution though, what about 2 services and a dash of IPC?
Use one native 64bit service to access the network share, and then when you
need to utilise the COM component you do so via some IPC to your second
service (a sort of COM proxy) running under LocalSystem? Not ideal
(performance, security) but it should get the job done.

If you do discover why it switches to 64bit when running under an AD
account, I'd be interested to know why. Have you tried it with a local user
account rather than an AD account?

Here's another thought that might be a much simpler solution - have you
tried running under the "NETWORK SERVICE" account instead? That's a local
machine account but should have network privs, maybe that would be the
answser?

Let us know how it turns out :-)
Alex
 
Hello All,
I had a similar situation; Service would start and run as Local Account, but would sit and hold in "Starting" when configured to run using any other account. I found that the service was trying to create a folder for temporary files. Once I gave the account permission to create/write to the folder the service started and ran as expected. In the end this had nothing to do with 32/64 bit-ness. It was the difference between running on Windows 2003 and Windows 2008.
 
Back
Top