Application freezes / Huge registry queries / App-V 5.1 Win10 RRS feed

  • Question

  • Hello everybody,

    I am from Germany and we currently discover an issue with a sequenced application. First, the same application works with App-V 4.6 but with 5.1 we have a strange behavior. The issue is the same on Win10 1607 and 1703 as well as Win7.

    The application launch is quick and without problems. But when we try to open the first menu, the application starts to do a huge number of registry queries (mostly in HKCR). When the app is started natively (without App-V) I see about 120.000 quries in ProcMon and finally the menu opens in under 10 seconds (see screenshots).
    Compared to App-V the same selection creates millions of registry queries (ProcMon crashed at 20.000.000) and this takes about 60 to 90 seconds. In this time the app does not respond, but afterwards the menu is displayed correctly.

    When we try to select the same menu again it opens in just seconds. So the delay is only the first selection after the application has started.

    We already tried a lot troubleshooting, for example disabling the virtual registry but without success!

    In the attached screenshot of Procmon you can see the HKCR queries. It seems like the application creates a kind of index of the registry?!

    I hope you may have an idea! Any help is highly appreciated!

    if you need any more information, feel free to ask.

    Thanks and regards,

    • Edited by jandowa Thursday, August 24, 2017 8:26 AM
    Thursday, August 24, 2017 8:16 AM

All replies

  • It seems like it's just querying the whole classesroot looking for something. Are you able to contact the vendor of this app? What is it looking for? Same for the native install... why query all those regkeys?
    Anyhow, you said on appv4 there where no issues. Did you convert the appv4 package, or did you a resequence? Try to resequence, and this time use PVAD, and point to installdir. Check out this article, which explains on howto enable pvad.

    Roy Essers

    Thursday, August 24, 2017 1:45 PM
  • Yes that's what we thought, too. We already contacted the vendor and we are waiting for a reply.
    I did not convert the package but did a full resequence.
    Thanks for that hint with PVAD. I will test that and report back here.
    Thursday, August 24, 2017 1:58 PM
  • An app that repeatedly enumerates all of HKCR isn't going to be a good candidate.  PVAD isn't going to help that.  If you can eliminate all HKLM\Software\Classes and HKCU\Software\Classes and HKCU\Software\Classes from the package you should eliminate the slowdown, but if the app has COM this will create other issues.

    Tim Mangan MVP for App-V and Citrix CTP Author of AppV books: "PowerShell with App-V 5 (5.1 Edition)", "The Client Book (4.x)" and "OSD Reference Book" ( )

    Thursday, August 24, 2017 7:11 PM
  • Hi,

    We faced a similar kind of issue in an In-House application.

    We were able to resolve the issue by appending the below registry path to PassThroughPaths registry key:


    PassThroughPaths  is an App-V Client registry and can be located at below path:


    You can also give a try.



    Mohit Kapoor

    Sunday, August 27, 2017 6:59 PM
  • Hello, so I tried to re-sequence the app with PVAD turned on, but according to Tim Mangans reply it unfortunately did not help.

    Wednesday, August 30, 2017 11:32 AM
  • Hi Mohit,

    thanks for that hint. We tried it, but unfortunately without success!

    Wednesday, August 30, 2017 11:33 AM
  • Hello Tim, you are right, PVAD did not help.
    Next up we will try to eliminate all HKLM\Software\Classes and HKCU\Software\Classes from the package.
    I will report back if this will help us.
    Wednesday, August 30, 2017 11:36 AM
  • Hi again,
    this time we tried and eliminated all registry keys in the package. That means no registry keys in the virtual registry right?

    Sadly we discovered no performance gains and with the keys eliminated the application throws an error at startup.

    So I think this candidate is more likely to be installed natively...

    Wednesday, August 30, 2017 12:25 PM
  • Did you also try to convert the appv4 package with the appv5 converter (sequencer)? Are you able to share the install source, so we could give it a try?

    Roy Essers

    Wednesday, August 30, 2017 8:49 PM
  • I know this is an old thread but as there is still no answer in here: Have you ever found a fix / workaround? I've got the exact same issue with one application. When virtualized (and we publish to user, not computer) I see the exact same. Millions of HKCR lookups. When running the application locally, it also does those lookups but 'only' about 19000. Still a lot. But when virtualized, the same action generates over 10.000.000 enumerations, I stopped logging there.

    I excluded classes in the package for both HKLM and HKCU, but still the issue is the same. I've gone as far as to put HKLM\Software and HKLM\System\Services in PassThroughPaths completely (we do have some specific paths in there, and the WinSock2 was already there). I ended up with HKCR in passthrough too. It breaks AppV pretty much like that, but alas the HKCR issue still manifests.

    Disabling COM isolation completely in the deplyment XMLs: doesn't change anything.

    Why or how does AppV interfere THAT much with those classes lookups? Some overhead is fine, but it's beyond me why it would generate 1.000 times more regsitry queries.

    Is there anything else, besides running non-virtualized which is not really an option, to work around this? Any help or insights are appreciated.

    Tuesday, July 16, 2019 10:29 AM
  • The only thing I have been reading about this kind of problem and a solution is this:

    • Proposed as answer by Arne Johansen Wednesday, September 4, 2019 5:57 PM
    Thursday, July 25, 2019 1:08 PM
  • After my vacation I'll try that. I consider this a huge flaw in AppV 5 though. As said, some overhead is to be expected, but with these HKCR 'scans' something goes horribly wrong.

    I'll report in a few weeks when I'm back at work. Thanks!

    Thursday, July 25, 2019 1:43 PM
  • I can't mention this enough...

    If you think this is a bug in the App-V client, you have to open a ticket with Microsoft.  They will not address App-V issues without a ticket.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (

    Thursday, July 25, 2019 2:40 PM
  • I can't mention this enough...

    If you think this is a bug in the App-V client, you have to open a ticket with Microsoft.  They will not address App-V issues without a ticket.


    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (

    I'll tell you how it works. I am in a small company. Actually, there's only two people and for what it's worth, I own the joint. We have a fair number of customers we do mostly hosted RDS services for. However, given the size of our company and it's revenue and resources we can put into specific things, we don't satify the requirements for a Microsoft Premier contract. We do have a SPLA contract with them, but that does not cover support. That means our only option is Microosft 'Pro' Support.

    ProSupport is a trainwreck if I've ever seen one. At first, officially they only do 'break-fix' scenarios, meaning they only MIGHT do something if you can prove it worked before, bug or not. In this case, this most probably never worked well in AppV5, so there's the first barrier.

    Then there is the overall quality of support within ProSupport. They will first bug you with days, sometimes even weeks of completely useless questions, logfiles and stuff, before someone even wants to do a remote session to actually let me show them what the issue is. Also, without being rude or rascist at all, most of them are Indian, or at least not native English speakers. While that doesn't mean anything in terms of technical knowledge, there is certainly a language barrier here.

    Then there is the fact that ProSupport does EVERYTHING in order NOT to do anything. Sometimes I've even had the message that our company is too small to justify fixing a specific bug for us. One example of that is this one: I've reported this to ProSupport but they just wouldn't work on it at all. A few weeks ago it became big news and what would you think? Now they start realising it's really a severe security issue.

    Also a few months ago I reported a bug in the DPI scaling when RDS is enabled on Server 2019. First answer was, we only do break fix. So I tell them I know that, and even that I have a workaround for my specific environment, but that I'd like to report a bug to Microsoft in order for them to improve Windows and prevent other people for running into the issue. After weeks of bullying me they just closed the ticket with 'We tried everything we could but we can't fix this issue'.

    From the last 12 (no kidding!) issues I raised with ProSupport, only ONE got fixed after 11 months. We as a small company just don't have any serious means to log issues with Microsoft. In stead, we are being laughed with as being too small, and are given a candy every now and then but in the end they mostly never resolve anything at all.

    No. While I have had serious issues with this specific AppV issue, I'm not going to raise a ticket. It's useless and worthless. Sorry. MS ha a totally useless support machine for us.


    Friday, July 26, 2019 12:20 PM
  • The only thing I have been reading about this kind of problem and a solution is this:

    I was still to test this. And setting the classes in HKLM in the package to override makes it work rather fine. Setting COM_MODE to “None” doesn't work though.

    As far as my testing goes, for this application it doesn't break anything either. So setting the classes to override seems to be a very good solution here! Thanks!

    Wednesday, September 4, 2019 3:05 PM
  • Nice 🙂
    Wednesday, September 4, 2019 5:58 PM
  • I don't like to recommend this, as it causes problems with connection groups.  But if you are not using connection groups you can enable the Container Registry (CREG) in the client rather than VREG.  CREG performance is much better for a lot of operations, but it isolates registry at the package level.

    This might not solve your problem either, but it might.

    App-V MVP & CTP Fellow. Author of AppV books: PowerShell with App-V 5, The Application Book, & Window Caching (

    Wednesday, September 4, 2019 8:57 PM