none
App-V 5, Application gets access violations

    Question

  • This application already had the issue with network launched exe. This was resolved by giving the host machine read/list access on the file path where the application stores it updated exe's and files.

    The application appeared to work well after this, but had not undergone user testing. When piloting the application on our 2008 R2 App-V 5 we get reports of errors in some situations.

    • This application had the 0xc0000142 "launching network executable in app-v error", but was resolved by giving the app-v client computer read/list on the path (see http://packnowledge.wordpress.com/2013/03/20/launching-a-network-executable-inside-an-app-v-5-virtual-environment-2/)
    • The errors are consistent on the datasets (client in a accounting app), but only for a smaller subset of datasets.
    • Most datasets work just fine.
    • The application works 100% sequenced in App-V 4.2 in our 2003 R2 x86 environment.
    • The application work when natively installed on a test VM set up just like the production client. (ie it's not bitness)
    • Tried giving the App-V host computer full access to network path, no change.

    The errors look like this:

    "Exception EAccessViolation: Access violation at address 50040950 in module 'xxxxx.bpl'. Read of address 465986CC."

    Trying to open the same dataset a second time will throw an error about file access. Apparently the application locks and doesn't release a file when first getting the access violation. Most likely only a clue to as to what file the app is working with as it fails, more than what fails. I suspect the difference in the datasets that trigger the bug is in this file, BUT this difference is not an issue in app-v 4 or natively installed.

    I realize this is pretty weak material to go on, but if anyone has experienced a similar error, specifically with this kind of network loaded exe-application perhaps I can look into that.

    I'll be moving on to procmon now, though an initial scan of procmon reveals nothing obvious.

    • Edited by Pål Røtnes Friday, August 16, 2013 9:25 AM small edit
    Friday, August 16, 2013 9:22 AM

Answers

  • Sorry, didn't have time to add the reply at the time. Tested by packaging the entire app (base program files + update-folder), didn't work any better.

    Boss called native install on it. Works like a charm now.

    Colleague of mine wrestled with another application and I spotted the same "operation= unlocksinglefile" and "range not locked" around what would be close to the error in his procmon log. Not going to waste any time investigating it further at this time, but looks like a plain bug or new weakness in App-V 5 as compared to 4, where both these apps work. (And thats 4.2 btw...)

    Thanks for the tips, I'll give it a shot again once SP2 arrives.


    -@gomibushi

    Friday, August 30, 2013 6:33 PM

All replies

  • Hello,

    Does the computer account have access to the datasets which are giving an error? Not just on the folder level, but for the specific files?


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

    Sunday, August 18, 2013 9:14 PM
  • Yes, no broken inheritance or exceptions as far as I can see.

    Would be very surprised if any diverging security settings were at that level.


    -@gomibushi

    Tuesday, August 20, 2013 1:17 PM
  • Hello,

    What does ProcMon say?

    Which accounts attempts to access the files?

    Are they locked by something?


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

    Tuesday, August 20, 2013 6:50 PM
  • Procmon says "operation= unlocksinglefile" and "range not locked" on a "lockfile" that the application (is supposed to) create for the dataset when in use. Literally its <clientid>.loc.

    The account used all of the time is the user account - not looking at every single operation, but really looks that way. 

    The files are not locked prior to the application throwing the error, but it locks one file and keeps it locked until it is closed down. This is a central "index" file with metadata about the dataset, so it is presumably used a lot when reading the dataset, which is when it throws the access violation.

    As far as I can see it is not possible for this to be rights-related as I have tried giving full access to everyone and running as administrator while debugging.

    Close to suggesting 4.6 SP2 in parallell...

    Should I post the PML file? (if you fancy a puzzle...)


    -@gomibushi

    Tuesday, August 20, 2013 9:05 PM
  • Hello,

    As a short-term solution, 4.6 SP2 would be the way togo.

    1. Have you tried placing the files locally (local-drives)?

    2. Have you tried enabling local-interaction (both of them)?

    (if you do so - please reset the client. Yeah, not kidding)


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

    Wednesday, August 21, 2013 6:13 AM
  • Sorry, didn't have time to add the reply at the time. Tested by packaging the entire app (base program files + update-folder), didn't work any better.

    Boss called native install on it. Works like a charm now.

    Colleague of mine wrestled with another application and I spotted the same "operation= unlocksinglefile" and "range not locked" around what would be close to the error in his procmon log. Not going to waste any time investigating it further at this time, but looks like a plain bug or new weakness in App-V 5 as compared to 4, where both these apps work. (And thats 4.2 btw...)

    Thanks for the tips, I'll give it a shot again once SP2 arrives.


    -@gomibushi

    Friday, August 30, 2013 6:33 PM