[RESOLVED] Why is my setup running virtualised?

In order to finish the project I am currently working on, I needed to gain access to the path of my setup exe application while it is running.

So I started by putting together a separate VB6 app which would return the full path of an exe file given one of its form's hwnd (windows handle). Then I ran my setup application, and fired up my test application at the same time. To my surprise I discovered that the path returned from the Setup file while it was running pointed to the AppData\Local\Temp directory (rather than its actual location on my hard drive) meaning that it seems to be running in virtualised mode.

The weird thing is that as the setup file contains the word "setup" Windows automatically asks for admin credentials so that it runs elevated with the rights needed to conduct the install. As far as I am aware elevating with Admin Credentials should have prevented any virtualisation from occurring, so why is my setup running virtualised?

maybe the point is that any setup is considered temporary, as in most cases it only needs to run once, to install some program

It probably isn't being virtualized, but without more detail it's hard to say.

A PDW setup package for example works by first running setup.exe which is a bootstrapper. This program's mission in life is to extract the rest of the setup files from the CAB archive (into a temporary location), install the VB6 runtimes, setup kit, and setup uninstall programs if included, then run setup1.exe.

So are you really looking for your setup1.exe program in this case? That would be in a temp folder.


People often wrap a PDW or other setup package in a self-extracting archive. When this "single EXE" is run it extracts the setup package into a temporary folder and then runs the setup.exe or equivalent program, or runs msiexec against an MSI file, etc.

Thank you for that good almost comprehensive answer dilettante, after thinking about it I agreed that the setup app might be trying to use the temp directory for extraction purposes, and even though I had checked two windows obtained via spy++, I decided to check all of the associated windows linked to the setup and found one that was running from the Hdd file location with an entirely different process Id.

So the bootstrapper architecture you mentioned seems to be implemented in my case, specifically, a bootstrap setup process starts to run from the HDD, which then creates at least one sub process which runs from the User\AppData\Local\Temp directory which performs other installation tasks most likely involving decompression and creates additional windows as it does so, no virtualisation whatsoever. :thumb: