Redirection to SysWOW64 folder?

Hey, guys.

I've recently started App-v sequencing for 64 bit OS and need some help. I've sequenced an app (it's a VFS install), which works great when streamed to a Windows 7 32bit client. As a test, I've also sequenced it on 64bit Server 2008 (using the 64-bit sequencer). When I streamed it down to a 2008 Terminal Server (64bit), I've run into problems.

I'm running a pre-launch dependency script, which runs an exe residing in the system32 folder. Anyway, basically it doesn't run (on 64bit OS - it works fine on 32bit OS) and I'm pretty sure it's to do with redirection on a 64bit OS.

My script simply calls the executable name. No path is specified because it sits in the System32 folder and that is set by the path environment variable etc.


So I've opened up a command prompt in the System Guard and had a look around.

I've found that sample.exe file exists in:


If I run the exe manually (in the command prompt) from C:\Windows\SysWOW64 or Q:\test.app\VFS\CSIDL_SYSTEM, it runs fine. If I run it from inside C:\Windows\System32 or from any other directory for that matter (thus relying on the Path env. variable to locate it), I get 'The system cannot find the file c:\windows\system32\ingwrap.exe' - even though it exists???

So, it seems that my script is trying to run the sample.exe in the System32 folder, as opposed to the SysWOW64 folder. If I change my script launching code to:


....then everything works fine. But it just concerns me why it isn't redirecting properly, and hardcoding this path isn't really the solution is it?

I'm just about to get procmon'ing, but I thought if anybody has encountered this issue before you can save me a big chunk of time which I don't have..... I've searched this forum and can't find much on the issue. I should mention that I've not been sequencing for too long, and I've not done much work on 64bit OS either, so I'm all ears.


0 Comments   [ + ] Show comments

Answers (3)

Posted by: captain_planet 11 years ago
Black Belt
Procmon didn't help me too much. I loaded a command prompt from a dependency script:


and in this command prompt, I ran Procmon.exe. Then I ran my sample.exe. Procmon returned the following (but the exe still didn't run):

QueryInformation........................c:\windows\syswow64\sample.exe..................NO SUCH FILE

But then if I run 'c:\windows\syswow64\sample.exe' from the command prompt, it launches fine? Hmmm. I'm confused.
Posted by: Rheuvel 11 years ago
Brown Belt
I haven't really looked into any 64bit OS either, so I can't help you with that. However... Out of curiosity now, I do wonder what behavior it shows if you run the 32 bit sequence (which was working great on 32 bit OS) on a 64 bit OS.

According to this page that sort of thing is supported. And because the sequence from the inside looks quite different depending on whether you sequence it on 32 bit or 64 bit machines I really wonder what the 64 bit app-v client does to the 32 bit sequence.

It might either work like a charm, make it worse than it already is, or maybe doesn't change a thing... [;)]

All you have to do if you still have the 32 bit sequence:
Sequence the 32-bit app on a 32-bit OS using the 4.6 sequencer. Specify x86 and x64 platforms as targets as appropriate for clients.

Good luck!
Posted by: captain_planet 11 years ago
Black Belt
Hey Rheuvel,

Yeah, I tried that. But it behaved exactly the same.....For now I can call '%windir%\SysWOW64\sample.exe' to get around the issue. I'm actually unable to fully test the app due to back-end connectivity etc, so it does concern me.....
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ