We have been working on updating a customer’s network to a new set of servers and PCs. The customer purchased Open License licenses for Windows 8.1 so we could image the PCs, rather than setting each one up individually. We decided to use the Microsoft Deployment Toolkit to deploy these images over the network rather than deploying the image via a USB/CD.
We installed a few applications that did not have server components initially. After the server components had been upgraded, we installed the client components for these pieces of software on the PC we were using to build our image. We then installed Microsoft updates. I had planned to start imaging the PC the next morning, but when I arrived the error message below was on the screen.
I received buffer overflow messages when troubleshooting with Process Monitoring and errors like this appeared in the Event Viewer:
I thought the problem might be with the image PC, so I rebuilt the image. After installing updates on the second PC and letting it sit overnight, the second PC started giving me the same errors. I knew this was not a problem before the second set of software was installed and updates were applied. I started looking into all of the updates that were installed, but realized this was going to take a long time because there were over 100 updates that had been installed. I decided to rebuild the image again, but not install updates. After doing this, the same error occurred after letting the PC sit powered on for about five hours.
After doing some testing, I found that it was only Windows applications that would give these error messages (PowerShell, Internet Explorer, Notepad, etc.) I started looking at the programs that were installed in the second set of updates instead. My theory was that one of these applications could be causing the problems and that it was likely that the program hooked a Windows process somehow. The only software that was installed that met this criteria was PrintAudit, which is a program that tracks print jobs so the cost of printing files can be passed on to the customer. Having three PCs to test on, I uninstalled PrintAudit from one of the PCs, waited overnight, and did not have any errors the next morning. I also built a Windows 8.1 VM and only installed PrintAudit. The VM with only PrintAudit installed gave the same errors after about 5 hours. Uninstalling the PrintAudit client would return the PC to a working condition.
I contacted PrintAudit tech support and they said that Windows 8.1 was supported and that they had others customers running Windows 8.1. During this time I found that adding one of the applications that was throwing the errors to the PrintAudit exclusion list would cause that application to run properly. I also contacted Microsoft and they examined the PC. They did not find any errors in the OS and said the problem was with the PrintAudit software.
I contacted PrintAudit tech support again and they attempted to recreate the problem, but were unable to do so. Both PrintAudit and myself were running Windows 8.1 on 64 bit virtual machines. After thinking about what could be different in my setup and the setup at PrintAudit tech support, I realized that the license key on my VMs were not activated. They were not activated as I did not want to use an activation on a machine that was going to get reimaged. I asked PrintAudit tech support if their VM was licensed and they said it was. As a test, I activated my testing VM, waiting overnight, and did not have any problems the next morning.
This shows that there are some Windows processes that do not work on an unactivated copy of Windows 8.1. There is some evidence of this on the Internet, but Microsoft has not confirmed nor provided a list of things that do not work on an unactivated copy of Windows 8.1.
