Application not launching through virtual bubble RRS feed

  • Question

  • Hello,

    We've encountered a problem with launching application via virtual bubble.

    App-V 4.6 sp1 , Windows server 2008 R2.

    The thing is:

    We have application that is physically installed on the server. Launching it just by double click to executable is working just fine (connects to sql server (we can see logon screen))

    But if launch it throuh virtual bubble (ie my app-v package containt ONLY one osd that points to physical executable and nothing more is included into package) it is failing to connect to db.

    Tried to enable\disable local interaction... Changed working directory (this has no impact on application nor physically, nor virtually). looked through procmon (in procmon it is clearly visible that it even is not trying to connect anywhere)

    Application has additional GUI that helps to test connection with DB , and this one is working correctly and shows that connection to DB is successful.

    Do you have any ideas\suggestions what could be causing this and how it could be fixed ( if it could ).

    Please advise.

    Thanks in advance.

    Monday, November 26, 2012 12:45 PM

All replies

  • How does the application connect to the database back-end? Via an ODBC connection etc.

    If it's ODBC run ODBCAD32 from within the package and confirm that the connection works OK from there.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or other MVPs.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V

    Monday, November 26, 2012 1:13 PM
  • Hi Aaron ,

    Thanks fo fast reply.

    Application connects to DB with this connection string:

    Provider=SQLOLEDB.1;Persist Security Info=True;Initial Catalog=HLonn;Data Source=SERVER\INSTANCE;User ID=USER;Password="xxxxxxxx";

    ODBCAD32 works well from both physical and virtual location(application even has gui which is also suceeds).

    During procmon investigation, I've found that application even don't try to connect to server (connection string isn't read from registries).

    Application has prerequisites:

    1. MDAC

    2. MS SQL server 2005 backwards compatibility

    As previousely mentioned, all components are installed physically.

    Monday, November 26, 2012 1:32 PM
  • Hello,

    Sounds like you have a conflicting value within the package. I suggest you verify that no value within the package overrieds a native value that you actually require

    Nicke Källén | The Knack| Twitter: @Znackattack

    Monday, November 26, 2012 11:05 PM
  • Hello,

    As I mentioned before - package is completely empty. Just an .osd file that points to the physically installed executable. When launched just with double click from physical environment - application works. When launched with .osd from virtual environment - application fails to work correctly(even before it tries to connect to DB).

    So, here we face problem where virtually application works differently, thus is failing. I hope that you could point me to the probable differences between virtual and physical application execution.

    One, that I'fe encountered earlier with another application, is DEP. Crystal reports component failed to function under App-V with switched on DEP. When I switched off the DEP for the main executable, application worked like a charm as App-v. So, prolbem was, as I understand, that under App-v application executed in another memory space, which was considered as malware and blocked by DEP.

    In current situation, I've already tried to switch off data execution prevention, but this didn't fixed the problem. So, I'm seeking for similiar solutions.

    Tuesday, November 27, 2012 8:20 AM
  • Hello,

    Any reason the virtual application wouldn't read a native registry key, if there isn't any conflict between the native environment and the virtual environment?

    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, November 27, 2012 9:10 AM
  • Hello,

    No reasons, I guess. But, fact still stays the same - package is completely empty, so conflict isn't possible.

    Maybe .dlls call some functions that are restricted under App-V ? This is what I'm asking - differences between virtual and physical executions. This isn't just about registry reads/writes.

    How application was captured:

    I've prepared VM by installing sequencer and target application. Verified that application works by launching it several times.

    During sequencing I've launched cmd.exe as installer for package and just closed it. Created .osd file that points to physically installed application executable. I haven't launched application during sequencing. Sequencer captured only some trash registries - i've deleted all of them.

    And saved the package - so it's COMPLETELY empty. just an osd file.

    Package test:

    Publish package from App-V server. Launch clean machine with App-V client. Install target application physically + verify that it works by launching several times(application connects to DB, logon screen received - success). Then I launch virtual package - bubble initiates correctly, application UI starts and I receive "connection to DB dropeed" error message which indicates a failure. I've then started virtual bubble with cmd:

    sfttray.exe /exe cmd "package name"

    and verify some physically installed applications like notepad.exe or word.exe from withing virtual bubble - all could be launched without any problem. Tried to launched my application from that command prompty - the same error("connection to DB dropeed").

    If I start application with double-click(physically) - it launches correctly and connects to DB.

    I've seen in procmon that virtually connection string(which is stored in application-specific registry key) even isn't started to be read. So, the problem is somewhere in initialization phase. Maybe some com objects couldn't be identified ? Unfortunately, I wasn't able to detect reason for failure in procmon logs, but I feel that it should come from some .dll functionality.

    Tuesday, November 27, 2012 11:03 AM
  • Hello,

    Is there a DLL functionality loaded in a working scenario, that you are not seeing in a non-working scenario ?

    Nicke Källén | The Knack| Twitter: @Znackattack

    Wednesday, November 28, 2012 10:31 PM
  • Hello,

    Is there a DLL functionality loaded in a working scenario, that you are not seeing in a non-working scenario ?

    Nicke Källén | The Knack| Twitter: @Znackattack


    I've used RegDllView.exe tool functionality to see loaded dlls from inside virtual bubble and from outside. Both registered .dll lists are the same.

    I've also tried to register some custom .dlls in virtual bubble to verify that they are registered only in virtual bubble and not seen from physical environment. This is also successful, which means that previous test results were correct.

    Second thing whith what I've tested is msinfo32.exe windows built-in tool, Loaded modules tab. The only difference noticed there is that from virtual bubble it additionally loads sfttray.exe.

    Loaded modules are exported as text and compared with text diff tools, which makes human error not possible.

    So, yes, it seems that dll functionality is loaded the same in physical and virtual envionemnt.

    If I've done something wrong, please describe with what tools I should measure working/not-working states.

    But for now, problem stays the same - application runs when launched physically and fails when run from virtual bubble even if in both situations it's fully installed physically in OS.

    Wednesday, December 5, 2012 11:34 AM
  • Hello,

    Sorry - I have no idea what to look at as you are always saying that everything looks the same, apart from the registry keys which are impossible to conflict with any resource within the virtual environment.

    Since you always describe the conclusions that say you shouldn't have a problem, as opposed to the findings that cause you to draw the conclusion I am completely out of ideas.

    Yes, it should work if everything you say is truely the way you are describing them.

    Nicke Källén | The Knack| Twitter: @Znackattack

    Wednesday, December 5, 2012 8:21 PM