Jump to content

Windows Error Message after upgrade


Super6VCA

Recommended Posts

Needed to upgrade Win11 version from 21H2 to a version that can be updated.  My desktop could not be upgraded any further.  After building and optimizing my new desktop, all my desktops get an error message as soon as desktop is loaded.  The error is Explorer.exe - System Error  The system detected a stack-based buffer in this application.  The overrun potentially allow a malicious user to gain control...  I get this error now on EVERY desktop i try to deploy.  I tried a few things when i looked up the error but they are all windows fixes.  i don't believe that windows is causing it.  I get  this on 22H2 Pro, 22H2 ENT, and 23H2 ENT.  Once again this only happens once i deploy a new pool.  Never had this error on 2206.  Now that i am on 2312.1  and still have it every time.  Any help is appreciated.  Thanks

View OS error.jpg

Thank you, Perry
Link to comment
Share on other sites

56 minutes ago, Super6VCA said:

Needed to upgrade Win11 version from 21H2 to a version that can be updated.  My desktop could not be upgraded any further.  After building and optimizing my new desktop, all my desktops get an error message as soon as desktop is loaded.  The error is Explorer.exe - System Error  The system detected a stack-based buffer in this application.  The overrun potentially allow a malicious user to gain control...  I get this error now on EVERY desktop i try to deploy.  I tried a few things when i looked up the error but they are all windows fixes.  i don't believe that windows is causing it.  I get  this on 22H2 Pro, 22H2 ENT, and 23H2 ENT.  Once again this only happens once i deploy a new pool.  Never had this error on 2206.  Now that i am on 2312.1  and still have it every time.  Any help is appreciated.  Thanks

View OS error.jpg

Hi @Super6VCA,

Did you follow the proper deployment method for the new Windows 11 image, using Windows ADK and WinPE (so that the image can be deployed without a vTPM)?

Because of the requirements to create a Windows 11 VM without vTPM, you cannot upgrade as the upgrade will fail since the base image doesn't have a vTPM.

If you did deploy the base image using the proper guidance, can you let us know what you've installed on the VM? As well as versions of the Horizon agent, and any other components that are related.

Cheers

Stephen Wagner (President, Digitally Accurate Inc.)

VMware vExpert (vExpert Pro, vSphere, vSAN Awards), Omnissa Tech Insider, NVIDIA NGCA Advisor, VMUG Leader, and Director (Board of Directors) at World of EUC

Check out my Tech Blog: https://www.StephenWagner.com

Link to comment
Share on other sites

I did the install manually.  i deployed many Win 11 desktops in my days.  i did however remove the TPM prior to creating the snapshot to deploy.  I followed the KB article on creating and optimizing a desktop.  Actually tried it with and without TPM and get the same results.  This error message doen't come up on the master image at all.  Only when i push out a new image.  If there is a different KB to follow please let me know.  At this point i will try anything

Edited by Super6VCA
Thank you, Perry
Link to comment
Share on other sites

A vTPM, once added to a Windows 11 instance, should never be removed.

For proper deployment, you must use Windows ADK and WinPE to deploy a Windows 11 base image without a vTPM (as in, never attaching it).

Instructions here: Deploy Windows 11 in virtual machine using bootable Windows PE (WinPE) Image (broadcom.com)

NOTE: In step 5, skip the "copy Unattend.xml C:\test\mount\" as you don't want to use this (it's an optional step).

Once you do this, create your WinPE media, and install Windows 11, you can continue to use the TechZone article on how to create a base image.

Stephen Wagner (President, Digitally Accurate Inc.)

VMware vExpert (vExpert Pro, vSphere, vSAN Awards), Omnissa Tech Insider, NVIDIA NGCA Advisor, VMUG Leader, and Director (Board of Directors) at World of EUC

Check out my Tech Blog: https://www.StephenWagner.com

Link to comment
Share on other sites

My environment is also experiencing this issue, and we're unsure of the cause as well.

I'm going to write out the text of the message here so others might find it more easily if doing a web search:

Quote

explorer.exe - System Error: The system detected an overrun of a stack-based buffer in this application. The overrun could potentially allow a malicious user to gain control of this application.

Some details:

  • Cloned and in-place upgraded our Windows 10 v22H2 Golden Image to Windows 11 v23H2 back on 7/26/24 -- no issues post-upgrade and this message was not appearing
  • Following Windows Updates installation and pool recompose on 9/10/2024, test users started reporting seeing the message shown above.
  • Only non-admin users are seeing the message, admin users do not see the message a logon.
  • The message can be dismissed and the VM will function normally afterwards.
  • The message is not appearing on the Gold image.
  • SFC/DISM/etc all report healthy on the Gold image.

We also had upgraded our Gold image with a temporary vTPM attached, then removed it before creating and deploying new IC pools. Despite what @StephenWagner7 says, and what general feelings on best-practice indicate, the article here still states that this approach is workable:

Quote

Alternatively, you can create a golden image with a vTPM device and install Windows 11 in the standard way, and then remove the vTPM device after shutting down the golden image and before using it to create a pool. 

Our Gold image has no accounts that login anywhere, and nothing I can think of which should be stored in the TPM. Our Instant Clone pools are hybrid joined and setup with EntraID SSO via PRT, and the Clones appear to all be working fine except for this new issue. We do utilize UEFI & SecureBoot, but we do not enable VBS due to the presence of NVIDIA GRID.

I have not tried rolling back the August\September updates to see if this would resolve the issue, but I suspect that it would. Currently we're in a holding pattern since Windows 11 v24H2 is nearing support in Horizon, so we may wait to deploy Windows 11 and upgrade to 24H2 instead, which also may resolve the issue.

Somehow I suspect the issue is related to changes in the Start Menu or Explore integrations with the 'Microsoft Account' experience that was deployed around the same time, referenced here. We started seeing the message before enabling PRT issuance in our environment, however it did not resolve the issue and we continue to see the message even on VMs where the user successfully obtains a PRT.

Link to comment
Share on other sites

Folks, please please please, do not upgrade your Windows 10 base/gold images to Windows 11. This is a large part of where all your issues are coming from.

Just deploy a new image.

  • Like 2

Stephen Wagner (President, Digitally Accurate Inc.)

VMware vExpert (vExpert Pro, vSphere, vSAN Awards), Omnissa Tech Insider, NVIDIA NGCA Advisor, VMUG Leader, and Director (Board of Directors) at World of EUC

Check out my Tech Blog: https://www.StephenWagner.com

Link to comment
Share on other sites

I agree 100% with @StephenWagner7.  In-place upgrade is fine for individual physical laptops and desktops.  And you may have to do it for some persistent VDI.

But you should NOT do an in-place Windows version upgrade if you're building non-persistent VDI or managing your templates.  Build a new image on the version of Windows that you're targeting and deploy that instead. 

  • Insightful 1

Sean Massey
Independent Consultant/Analyst/Blogger | VCDX-EUC 247
Vice Chairman of the Board - World of EUC
Blog: thevirtualhorizon.com  Mastodon: @seanpmassey@vmst.io Instagram/Thread:
@seanpmassey LI: https://www.linkedin.com/in/seanpmassey/

Link to comment
Share on other sites

5 hours ago, StephenWagner7 said:

This is a large part of where all your issues are coming from.

 

3 hours ago, Sean Massey-1 said:

you should NOT do an in-place Windows version upgrade if you're building non-persistent VDI or managing your templates

Citation Needed.

Gentlemen, I'm all for constructive criticism, but at some point you just have to trust the process. I generally agree that starting from scratch and deploying programmatically leads to the most reliable platform, however this deployment methodology is not appropriate for everyone -- and deferring to it as knee-jerk panacea-style solution for every issue isn't conducive to successful troubleshooting. Try to stay on topic please.

In our case, we have 195 applications installed on the Gold, and years of deep customization and troubleshooting to make everything work nicely. Maybe this is technical debt, hard to say really. But building a new image is no small feat for us. We are a small team supporting a large and complex user environment, so resolving issues is preferable to starting from scratch in almost every scenario. Cattle vs Pets maybe, again, hard to say.

For anyone else experiencing this issue ( @Super6VCA ) , I was able to resolve this today with some additional troubleshooting. In our environment, we found that the UEM\DEM profile for 'Start Menu' was causing the issue. We had made some OS-specific profiles for various things but we had left the default 'Start Menu' archive applied to both Windows 10 and Windows 11. By limiting the default 'Start Menu' profile to just Windows 10 via condition, and creating a new profile for Windows 11 (also limited via condition), we no longer see the issue occur. I suppose there is some old junk in the Windows 10 Start Menu archive that no longer play nice. The loss of Start Menu customization between Win10/Win11 environment transitions is acceptable for us, so this solution is a good one long-term.

Link to comment
Share on other sites

4 minutes ago, nda said:

 

Citation Needed.

Gentlemen, I'm all for constructive criticism, but at some point you just have to trust the process. I generally agree that starting from scratch and deploying programmatically leads to the most reliable platform, however this deployment methodology is not appropriate for everyone -- and deferring to it as knee-jerk panacea-style solution for every issue isn't conducive to successful troubleshooting. Try to stay on topic please.

In our case, we have 195 applications installed on the Gold, and years of deep customization and troubleshooting to make everything work nicely. Maybe this is technical debt, hard to say really. But building a new image is no small feat for us. We are a small team supporting a large and complex user environment, so resolving issues is preferable to starting from scratch in almost every scenario. Cattle vs Pets maybe, again, hard to say.

For anyone else experiencing this issue ( @Super6VCA ) , I was able to resolve this today with some additional troubleshooting. In our environment, we found that the UEM\DEM profile for 'Start Menu' was causing the issue. We had made some OS-specific profiles for various things but we had left the default 'Start Menu' archive applied to both Windows 10 and Windows 11. By limiting the default 'Start Menu' profile to just Windows 10 via condition, and creating a new profile for Windows 11 (also limited via condition), we no longer see the issue occur. I suppose there is some old junk in the Windows 10 Start Menu archive that no longer play nice. The loss of Start Menu customization between Win10/Win11 environment transitions is acceptable for us, so this solution is a good one long-term.

I'll try to provide some relevant documents later on providing information on recommended deployments. But I just wanted to add in that if you have that many applications, you should be considering using App Volumes, as chances are the users don't require all those apps installed.

Normally for environments with that many apps:

  • Base Image with Office 365 baked in (and any frameworks required
    • Automation - Press key/button to generate on the fly, auto-updated, running latest feature release
  • Apps delivered with App Volumes

If you have a small team, this should help reduce the maintenance and troubleshooting of the solution.

Stephen Wagner (President, Digitally Accurate Inc.)

VMware vExpert (vExpert Pro, vSphere, vSAN Awards), Omnissa Tech Insider, NVIDIA NGCA Advisor, VMUG Leader, and Director (Board of Directors) at World of EUC

Check out my Tech Blog: https://www.StephenWagner.com

Link to comment
Share on other sites

Just now, StephenWagner7 said:

If you have a small team, this should help reduce the maintenance and troubleshooting of the solution.

Every iteration of application layering that we have implemented and tested (ThinApp, Unidesk before it was Citrix-owned, AppVolumes) has been a comical dumpster fire of added complexity. It certainly does not reduce administrative overhead -- it is just another solution to maintain and another point of contention to troubleshoot.

The issues with these solutions revolve around interdependency and common\shared features between layered applications. With a large and complex application set, eventually you will find a set of two (or more) layered applications that have conflicting binaries, shared dependencies (Visual C++ or Crystal Reports, for example), or conflicting registry keys, and then you'll spend inordinate time troubleshooting these conflicts so you can attach all your possible layer combinations without breaking things. 'Layer Priority' -- I don't miss it. Not to mention the significant loss of performance that can occur when attaching another file system filter driver that has to 'think' about where to direct your I/O.

Again, solutions like AppVolumes are certainly not one-size-fits-all. You're right that most users don't need most apps -- we restrict their access via AppLocker, and we don't mind that they can see the application shortcuts in the Start Menu. It's hard to understate the ease of management that comes with managing everything with a single image and no layering -- OS updates, application updates, recomposing... everything is dead simple with this approach and it's easily the lowest complexity approach for a small team to manage.

Link to comment
Share on other sites

2 hours ago, nda said:

Citation Needed.

There was a VMware KB that covered in-place upgrades for Horizon. Unfortunately, I am having trouble finding it now due to EUC being spun out. If I can locate it again, I will post it. 

Sean Massey
Independent Consultant/Analyst/Blogger | VCDX-EUC 247
Vice Chairman of the Board - World of EUC
Blog: thevirtualhorizon.com  Mastodon: @seanpmassey@vmst.io Instagram/Thread:
@seanpmassey LI: https://www.linkedin.com/in/seanpmassey/

Link to comment
Share on other sites

37 minutes ago, Sean Massey-1 said:

There was a VMware KB that covered in-place upgrades for Horizon. Unfortunately, I am having trouble finding it now due to EUC being spun out. If I can locate it again, I will post it. 

I am familiar with the article here which details OS upgrade support, including support for leaving the Horizon Agent installed for Full Clones during the upgrade. However this article does not reflect that OS upgrades are prohibited for IC pools or other Horizon use cases, just that the Agent should be removed before and reinstalled afterwards.

I am not familiar with any Horizon documentation that expresses a prohibition on in-place upgrades. The recommendation is always 'start fresh', of course, and again I agree that this is the best route overall. But sometimes the juice isn't worth the squeeze.

Link to comment
Share on other sites

1 hour ago, nda said:

I am not familiar with any Horizon documentation that expresses a prohibition on in-place upgrades. The recommendation is always 'start fresh', of course, and again I agree that this is the best route overall. But sometimes the juice isn't worth the squeeze.

You’re right. There is nothing that prohibits it.  It’s just a strongly held recommendation across almost the entire EUC space. 

The automation to support that recommendation is not one of those things that happens overnight. It can take years to get a completely automated build process, especially in complex and app-dense environments. 
 

I hope you understand that those of us who have a strong reaction towards in-place upgrades  have been burned in the past. 

Sean Massey
Independent Consultant/Analyst/Blogger | VCDX-EUC 247
Vice Chairman of the Board - World of EUC
Blog: thevirtualhorizon.com  Mastodon: @seanpmassey@vmst.io Instagram/Thread:
@seanpmassey LI: https://www.linkedin.com/in/seanpmassey/

Link to comment
Share on other sites

On 10/25/2024 at 5:02 PM, Sean Massey-1 said:

It’s just a strongly held recommendation across almost the entire EUC space. 

I agree with the recommendation in principal and in general. But it's not appropriate for all environments -- hence 'recommendation' and not 'requirement'.

On 10/25/2024 at 5:02 PM, Sean Massey-1 said:

The automation to support that recommendation is not one of those things that happens overnight. It can take years to get a completely automated build process, especially in complex and app-dense environments. 

Sadly, in a sufficiently complex and diverse environment, full automation of such a deployment is not even possible. We utilize a variety of applications that don't support scripted installation, and\or don't support scripted or file- or registry-based configuration. As such, even if we could automate >80% of the build, we'd still be spending many hours installing and configuring additional software, and then testing and troubleshooting the whole stack. Such as it is, we are burdened with supporting older and\or highly niche and specialized and tailored software, and there is not much to be done about it. Anyone who has worked in healthcare, municipal environments that support public services (e.g. police or fire), manufacturing, defense contracting, etc, are likely to understand this predicament.

On 10/25/2024 at 5:02 PM, Sean Massey-1 said:

I hope you understand that those of us who have a strong reaction towards in-place upgrades  have been burned in the past. 

I fully resonate with the feeling of apprehension here. I've seen plenty of upgrades go sideways in large and small ways, leading to catastrophic failure, system instability or just general weirdness. But I think the risks of such failures are largely mitigated in virtual environments (e.g. cloning, snapshots). And like I said, sometimes you just have to trust the process -- in-place upgrades have become the norm for workstation OSs (and increasingly so for Server OSs lately), and if Microsoft supports it then we should at least try and have some faith. Maybe faith in Microsoft is displaced for some, but Windows is still ~70% of global market share.

I'd also like to point out that, in my environment and this instance specifically, this issue would not have been resolved with a fresh build. Since my issue was driven by DEM, as soon as I installed the agent and recomposed I would very likely have been faced with the same error message again. In this case I'm glad I didn't burn untold hours on the process of building from scratch, and instead remediated the issue with appropriate troubleshooting methodology.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...