locked
App-V5.1 package corrupts local software (ms access error) RRS feed

  • Question

  • Hello,

    I have a local installed client application running on win7 x64 enterprise. The specific application is working fine over years. The application links a access 2013 database on start. On the same machine app-v5.1 client is installed. I have one app-v application (autocad mechanical) that only runs correctly when at the end of sequencing the option "allow all COM objects to interact with the local system" is activated. But, when autocad is deployed to the client my local application doesn't work anymore. On start it displays me an error that the access tables couldn't be linked.

    If I just close autocad the problem presists. The problem is gone, when I remove the virtual application from my system. So the virtual deployed application has a negative impact to my local installed application. I have no problem with my local application when I don't activate COM object interaction from the virtual application. But in this case my virtual application doesn't work fine..

    I've set by group Policy:

    EnableDynamicVirtualization = 0
    ProcessesUsingVirtualComponents = {}

    I've also tested with Windows 10. But with same results.

    Any Idea how to bypass or to fix that issue?

    Thank you!

    kind regards

    Matthias


    • Edited by m.niederehe Thursday, April 20, 2017 7:56 AM
    Thursday, April 20, 2017 7:54 AM

Answers

  • As soon as you enable COM interaction, there is no longer isolation, which means registry entries are layed down on your system pointing to the App-V package, where all local applications have access too... therefore it's called "integrated COM interaction". What happens if you install this virtualized application native on the client? Doe you experience the same problem?

    You can try the following:
    1) Perform a procmon trace for the action which is failing. Figure out what actually breaks the app.
    2) Revert sequencer to clean state, install the application which is having the issue on your sequencer. Resequence the application, and deploy.

    Roy Essers

    Thursday, April 20, 2017 10:29 AM
  • Hello togehter,

    first of oll sorry for my late answering but it took some time to test some scenarios.

    Roys answer brougth me to the solution. First I've tested a local installation, so I installed both applications native on the same client. Both applications working fine. Next I played with the COM objects. I turned on and off the COM interaction and tried to find out, which COM object is virtualized in the package that disturbs correct running of the native software. That took lots of time and at the end I still I couldn't find the unknown COM object.

    So I installed as Roy recommended in step 2 the not working native software as prereqisite and hoped that the COM object won't be installed while sequencing. That it :-) Now the native application and the virtual package are running fine. Thank you !

    kind regards from Luxembourg

    Matthias

    Tuesday, May 2, 2017 7:06 AM

All replies

  • As soon as you enable COM interaction, there is no longer isolation, which means registry entries are layed down on your system pointing to the App-V package, where all local applications have access too... therefore it's called "integrated COM interaction". What happens if you install this virtualized application native on the client? Doe you experience the same problem?

    You can try the following:
    1) Perform a procmon trace for the action which is failing. Figure out what actually breaks the app.
    2) Revert sequencer to clean state, install the application which is having the issue on your sequencer. Resequence the application, and deploy.

    Roy Essers

    Thursday, April 20, 2017 10:29 AM
  • Also, did you launch the application during sequencing?  If so, try re-sequencing it without launching the application (or vice versa). 
    Wednesday, April 26, 2017 3:32 PM
    Moderator
  • Hello togehter,

    first of oll sorry for my late answering but it took some time to test some scenarios.

    Roys answer brougth me to the solution. First I've tested a local installation, so I installed both applications native on the same client. Both applications working fine. Next I played with the COM objects. I turned on and off the COM interaction and tried to find out, which COM object is virtualized in the package that disturbs correct running of the native software. That took lots of time and at the end I still I couldn't find the unknown COM object.

    So I installed as Roy recommended in step 2 the not working native software as prereqisite and hoped that the COM object won't be installed while sequencing. That it :-) Now the native application and the virtual package are running fine. Thank you !

    kind regards from Luxembourg

    Matthias

    Tuesday, May 2, 2017 7:06 AM