Last Updated on December 15, 2021 by rudyooms
This blog will be about some weird RunOnce behaviour when your brand new Win32 App failed to install without some proper error code. I will show you how to start troubleshooting failed Win32 Apps or when the App has a reboot pending
Some time ago I also did a blog about troubleshooting failed Win32App’s because of the IMECache that was cleared before the additional app could be installed
I will divide this blog into multiple parts
1. The Question
Let’s begin with the question. This week, a customer asked me to push their Nuance Dragon speech software to some specific devices. I guess I am a nice person, so I immediately created a new Win32App with some nice parameters.
To start testing, it’s always recommended to have a dedicated M365 test tenant for testing purposes with some test virtual machines. Or just use sandbox like I am showing in this blog
But let’s skip the wonderful Sandbox for now. So I enrolled a new virtual Windows 10 and waited until the application was installed. It took some time to download because the Intunwinapp was about 3,5 gb in total.
Please beware of the default configured max size, for an intunewin file this is 8 GB. (or you need to put in a service ticket and ask to increase it)
2. Troubleshooting the Win32App installation
But the installation took way too long… How are we going to monitor the Win32 app installation? First, you will need the app ID itself.
This ID is very easy to find. You will find the App Id/GUID, when you open the application properties in the Endpoint Manager.
Another possibility would be to just monitor the disk performance, you’ll notice the app will be downloaded. The app itself is downloaded in the incoming/staging folder. And the GUID is also mentioned like I am showing below
Now we have the Win32app ID/guid you can open the registry and take check out the status and error code.
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\INTUNEMANAGEMENTEXTENSION\SIDECARPOLICIES\STATUSSERVICEREPORTS
While installing the app, the status will still be Unknown… but after a while, it will change. After some moments of patience, the app was still not installed but this time Intune reported the Win32app with a failed install status: Fatal error during installation.
Now it’s time to take a good look at some client-side logging. The first one you’ll need to open will be the IntuneManagementExtension.log. Which is located in:
c:\ProgramData\Microsoft\IntuneManagementExtension\Logs
<![LOG[[Win32App] Sending results to service. session RequestPayload: [{“AppId”:”76912b57-9074-4306-b015-fb104e854087“,”InternalVersion”:1,”UserId”:”d0f774ca-96e9-4143-88c2-b4709d018a55″,”DeviceId”:”5caff78c-babe-4894-a547-60e12c581e97″,”ExitCode”:1603,”
This log showed me the famous 1603 error. So let’s check out the registry if it is telling us the same
You can open the registry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\SID\GUID
As shown below, it has the same exit code as the intunemanagement log! isn’t that a coincidence?
3. The Issue
With almost 20 years or so worth of experience the first thing that came to mind was: reboot pending! The first place to look (I thought) would be the pendingfilerenameoperations registry key:
HKEY_LOCAL_MACHINE \System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
But there were no pending file rename operations? That’s odd I was really expecting to see a nice reboot pending, but this time I guess not.
Luckily when you are deploying MSI files, there is a nice logging function you can use.
So I configured the msiexec to log all of its actions to a specific logfile with the /L parameter because I want to know why it broke as Intune doesn’t give us that information.
After clearing the Win32App in the registry, I restarted the Intune Management agent service. After a minute or 2, it started downloading again, but this time with a proper log file.
Script Info: 11-11-2020 15:08:15: Checking for pending system reboot...
Script Info: 11-11-2020 15:08:15: Checking registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
Script Info: 11-11-2020 15:08:15: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\Delete Cached Update Binary='C:\Windows\system32\cmd.exe /q /c del /q "C:\Program Files (x86)\Microsoft OneDrive\Update\OneDriveSetup.exe"' indicates pending OS reboot.
Script Info: 11-11-2020 15:08:15: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\Delete Cached Standalone Update Binary='C:\Windows\system32\cmd.exe /q /c del /q "C:\Program Files (x86)\Microsoft OneDrive\StandaloneUpdater\OneDriveSetup.exe"' indicates pending OS reboot.
Script Warning: 11-11-2020 15:08:15: System reboot is pending
Script Info: 11-11-2020 15:08:15: Cancelling installation because of pending reboot
So what could be the problem as the log file is telling us that the runonce key is telling us that key is indicating that t needs to reboot? That’s odd because the runonce key was not removed, not even after multiple reboots. Take a look at what Microsoft has to say about the RunOnce Key.
Can’t execute commands with RunOnce and RunOnceEx – Windows Client | Microsoft Docs
The difference between the run key and the runonce key is that applications listed under “RunOnce” key are only executed when a user logs in with administrator permissions, applications listed under the “Run” key are run when any user logs in.
4. Solving the Issue?
My first thought was to delete the key and most of the time the first thought that pops up is the best one! So I created a very simple PowerShell script to just remove the keys which were stuck and configured it in Intune.
reg delete HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\runonce /f
Again I enrolled a new VM to be sure it worked like expected. And yes it did, the PowerShell script removed the registry key and the application was installed finally.
But I was not done yet, there must be a different way to remove the “RunOnce” keys instead of removing them? After spending some time on google, I tried to run the next command under a normal user.
c:\windows\system32\runonce.exe /explorer
But that didn’t work. Running the same command “Run as admin” (and providing the local admin credentials) worked. It’s the same as logging in as admin to process the runonce key.
Conclusion:
When deploying Win32apps, you can run into unexpected installations errors so knowing how to troubleshoot app install failures is really necessary. Implementing admin less and restricting cmd can get you into some weird situations. I hope this blog will help you troubleshoot these errors and please don’t forget about the running (RunOnce) key.
If you are interested in my other blog about Troubleshooting Win32App’s here it is (again):