This is not so much description of a problem with the latest OS offering from Microsoft as it is a tale of how that bug effected my machine, and the global cooperation that finally identified and solved it.
Warning: This might get a little “techie” for some people. If that is you, just skip to the summary for the conclusions, and how this might impact you.
The gist of the problem is that alternate users on a Windows 10 system may have a failure in the User Profile Service and be unable to log on.
That is the problem I was having, but not the way it was showing itself on my machine.
Background
I use a very nice application development product from Unisys called Agile Business Suite (AB Suite – find out more about it on their web site here - http://www.unisys.com/offerings/high-end-servers/clearpath-forward-systems/cross-platform-software/agile-business-suite ). It has two major parts, a Development Environment that works as a package in Visual Studio, and a Runtime Environment that installs on a Windows server or desktop, and uses the latest Windows .NET environment and SQL Server.
In June of last year I bought a new laptop for business. It came with Windows 8.1, and right away I installed Visual Studio, SQL Server, and AB Suite 5.0. Then in July I upgraded to Windows 10, almost as soon as it was available. I did the recommended in-place upgrade, and everything seemed to go pretty well (see my blog entries about Windows 10, if you are interested).
AB Suite was not officially supported with Windows 10 at that time, and the clients I have been working with were using an older version, so I had either been using a remote server, or running AB Suite in a virtual machine on my laptop until the IC (Interim Correction) supporting Windows 10 came out around the first of this year. My work with AB Suite 5.0 was tabled until that time.
The Problem
In January I installed the IC (AB Suite IC 5.0.1018) that is qualified with Windows 10, and began to Build my small test application. AB Suite is a model driven development tool that will automatically generate the C# programs for your Windows environment, creates and installs the COM components, and even creates or reorganizes the SQL Server database for your runtime application. When I began to Build the application everything went very well, until right at the end of the process when it creates the database. The program REORGDB terminated with a strange error, saying “type mismatch”.
I assumed that since the program had worked before I upgraded the machine last summer that this must have something to do with the upgrade. Maybe it was a difference in SQL Server, or something with differences in the user account permissions granted in Windows 8.1 vs. Windows 10.
I did everything I could think of to try to resolve the problem, even to the point of uninstalling and reinstalling AB Suite, Visual Studio and SQL Server. It still was not working. So I contacted my colleagues in AB Suite engineering. They had never seen an error like this either. At their suggestion I checked the permissions on the two user accounts used by AB Suite – one is an application user that becomes the owner of the AB Suite runtime application, and the other is a special Administrator account that is used for various maintenance functions. I found one permission was missing from the AB Suite Administrator account, but fixing that did not correct this problem.
On the Trail
We had a remote debugging session, with me in the US, three locations in Australia, and one location in India. (The AB Suite engineering team is quite diverse and in many locations.) During the session we zeroed in on the two application accounts, App User and App Admin User. We discovered that the App User was not listed as a Login in SQL Server. Also, one of the engineers noticed that I was running under a Windows Live account, rather than a local administrator account. And then finally, we checked the Windows Registry and discovered that neither application account was listed under user profiles. All of this strengthened our belief that there was something wrong with one or the other of the application accounts, but we still couldn’t see what could have caused the problem.
The application accounts had not been created after I had upgraded to Windows 10, so we thought that might be the source of the problem. We agreed on three experiments. First I would remove AB Suite and the application accounts and allow AB Suite to create the accounts as part of the installation process under Windows 10. Next, if that was not successful, I would remove and reinstall AB Suite, this time using a local administrator account. And finally, if all else fails, remove and reinstall not only AB Suite, but also SQL Server and Visual Studio, this time using the local administrator account.
After all of these attempts I was still getting the same error in REORDB. Not only that, the accounts were still not included in the Profiles in the Registry.
Someone suggested logging on with these accounts to force the system to create Profiles for them. But I found that I was unable to log on. The system was unable to find or create a profile for these users.
This proved to be the key to solving the problem.
I found a forum posting on a Microsoft website that seemed to describe the problem I was having with the user accounts. The users said when they upgraded from Windows 8.1 to Windows 10 they were unable to log on their machine with child accounts. The error was the same one I was seeing, that the User Profile Service failed and profile could not be loaded.
Here is the link to that forum.
http://answers.microsoft.com/en-us/windows/forum/windows_10-security/windows-10-user-profile-service-failed-the-sign-in/3a39f75e-030c-4cd5-8b9f-c7bdaf77c41e?auth=1
The workaround that seems to work for most people is to either do a clean install of Windows 10 from the original release media, or to copy a user profile from another, working Windows 10 machine. Well I didn’t have the original release, and didn’t really want to go back to the beginning, even if I did. But at the same time, I wasn’t sure how I would go about getting a user profile from another, working Windows 10 machine.
Then I remembered that my home computer was also running Windows 10, but it had been upgraded from Windows 7 – not Windows 8 or 8.1. Following the advice in one of the answers in the online posting, I copied the default User profile from my previously Windows 7 machine to my laptop. Then I recreated the application accounts and was able to log on with them. The profiles were created, and they appeared, as expected in the Registry.
Then I reinstalled AB Suite, again, ran my application Build, and this time everything worked exactly as it should.
Just for good measure, I generated another AB Suite application, and this time it worked perfectly. Problem solved.
Summary and Conclusions
This problem was a strange one because the symptoms all pointed to some sort of permissions issue with the application user account, but everything else seemed to be working. I had followed exactly the same procedure I have used hundreds of times when installing the software, and the only significant variable was the levels of the software. It is exactly the type of problem you expect when testing with new release levels. But apparently no one had seen this problem before with AB Suite. It was because of the way I migrated my system from Windows 8.1 to Windows 10, which apparently introduces this problem with user accounts. Remember, I was following recommended Microsoft procedures, and did not see any other errors at the time.
How likely are you to have this problem?
For most people in a business environment this may not be a concern, because when you receive a new computer, or upgrade an existing one, it is probably set up by a help desk or tech support team, and they build your system from a standard system image that may have been tailored for your company. On the other hand, if you do your own upgrade, say because you received a notice about the free upgrade from Microsoft, or if you recently bought a computer that came with Windows 8.1 already installed, please be aware.
The problem was not hard to fix, but it was very difficult to diagnose in this case. Kudos and thanks to the Unisys AB Suite engineering team for their perseverance and support in tracking down this problem. Hopefully, since we have identified the problem and its resolution, you won’t have to go through the same frustration we did.
I don’t know if Microsoft has fixed this problem in later updates to Windows 10, but as recently as April 2016 some people still seem to be running into this problem.
As I said, the problem isn’t especially hard to work around, once you know what is happening, and what symptoms to look for, but getting to that point can be very frustrating and time consuming. So I am posting this history so others can benefit from this experience.
Warning: This might get a little “techie” for some people. If that is you, just skip to the summary for the conclusions, and how this might impact you.
The gist of the problem is that alternate users on a Windows 10 system may have a failure in the User Profile Service and be unable to log on.
That is the problem I was having, but not the way it was showing itself on my machine.
Background
I use a very nice application development product from Unisys called Agile Business Suite (AB Suite – find out more about it on their web site here - http://www.unisys.com/offerings/high-end-servers/clearpath-forward-systems/cross-platform-software/agile-business-suite ). It has two major parts, a Development Environment that works as a package in Visual Studio, and a Runtime Environment that installs on a Windows server or desktop, and uses the latest Windows .NET environment and SQL Server.
In June of last year I bought a new laptop for business. It came with Windows 8.1, and right away I installed Visual Studio, SQL Server, and AB Suite 5.0. Then in July I upgraded to Windows 10, almost as soon as it was available. I did the recommended in-place upgrade, and everything seemed to go pretty well (see my blog entries about Windows 10, if you are interested).
AB Suite was not officially supported with Windows 10 at that time, and the clients I have been working with were using an older version, so I had either been using a remote server, or running AB Suite in a virtual machine on my laptop until the IC (Interim Correction) supporting Windows 10 came out around the first of this year. My work with AB Suite 5.0 was tabled until that time.
The Problem
In January I installed the IC (AB Suite IC 5.0.1018) that is qualified with Windows 10, and began to Build my small test application. AB Suite is a model driven development tool that will automatically generate the C# programs for your Windows environment, creates and installs the COM components, and even creates or reorganizes the SQL Server database for your runtime application. When I began to Build the application everything went very well, until right at the end of the process when it creates the database. The program REORGDB terminated with a strange error, saying “type mismatch”.
I assumed that since the program had worked before I upgraded the machine last summer that this must have something to do with the upgrade. Maybe it was a difference in SQL Server, or something with differences in the user account permissions granted in Windows 8.1 vs. Windows 10.
I did everything I could think of to try to resolve the problem, even to the point of uninstalling and reinstalling AB Suite, Visual Studio and SQL Server. It still was not working. So I contacted my colleagues in AB Suite engineering. They had never seen an error like this either. At their suggestion I checked the permissions on the two user accounts used by AB Suite – one is an application user that becomes the owner of the AB Suite runtime application, and the other is a special Administrator account that is used for various maintenance functions. I found one permission was missing from the AB Suite Administrator account, but fixing that did not correct this problem.
On the Trail
We had a remote debugging session, with me in the US, three locations in Australia, and one location in India. (The AB Suite engineering team is quite diverse and in many locations.) During the session we zeroed in on the two application accounts, App User and App Admin User. We discovered that the App User was not listed as a Login in SQL Server. Also, one of the engineers noticed that I was running under a Windows Live account, rather than a local administrator account. And then finally, we checked the Windows Registry and discovered that neither application account was listed under user profiles. All of this strengthened our belief that there was something wrong with one or the other of the application accounts, but we still couldn’t see what could have caused the problem.
The application accounts had not been created after I had upgraded to Windows 10, so we thought that might be the source of the problem. We agreed on three experiments. First I would remove AB Suite and the application accounts and allow AB Suite to create the accounts as part of the installation process under Windows 10. Next, if that was not successful, I would remove and reinstall AB Suite, this time using a local administrator account. And finally, if all else fails, remove and reinstall not only AB Suite, but also SQL Server and Visual Studio, this time using the local administrator account.
After all of these attempts I was still getting the same error in REORDB. Not only that, the accounts were still not included in the Profiles in the Registry.
Someone suggested logging on with these accounts to force the system to create Profiles for them. But I found that I was unable to log on. The system was unable to find or create a profile for these users.
This proved to be the key to solving the problem.
I found a forum posting on a Microsoft website that seemed to describe the problem I was having with the user accounts. The users said when they upgraded from Windows 8.1 to Windows 10 they were unable to log on their machine with child accounts. The error was the same one I was seeing, that the User Profile Service failed and profile could not be loaded.
Here is the link to that forum.
http://answers.microsoft.com/en-us/windows/forum/windows_10-security/windows-10-user-profile-service-failed-the-sign-in/3a39f75e-030c-4cd5-8b9f-c7bdaf77c41e?auth=1
The workaround that seems to work for most people is to either do a clean install of Windows 10 from the original release media, or to copy a user profile from another, working Windows 10 machine. Well I didn’t have the original release, and didn’t really want to go back to the beginning, even if I did. But at the same time, I wasn’t sure how I would go about getting a user profile from another, working Windows 10 machine.
Then I remembered that my home computer was also running Windows 10, but it had been upgraded from Windows 7 – not Windows 8 or 8.1. Following the advice in one of the answers in the online posting, I copied the default User profile from my previously Windows 7 machine to my laptop. Then I recreated the application accounts and was able to log on with them. The profiles were created, and they appeared, as expected in the Registry.
Then I reinstalled AB Suite, again, ran my application Build, and this time everything worked exactly as it should.
Just for good measure, I generated another AB Suite application, and this time it worked perfectly. Problem solved.
Summary and Conclusions
This problem was a strange one because the symptoms all pointed to some sort of permissions issue with the application user account, but everything else seemed to be working. I had followed exactly the same procedure I have used hundreds of times when installing the software, and the only significant variable was the levels of the software. It is exactly the type of problem you expect when testing with new release levels. But apparently no one had seen this problem before with AB Suite. It was because of the way I migrated my system from Windows 8.1 to Windows 10, which apparently introduces this problem with user accounts. Remember, I was following recommended Microsoft procedures, and did not see any other errors at the time.
How likely are you to have this problem?
- If you install Windows 10 as a clean installation from release media – you probably won’t have this problem.
- If you upgrade to Windows 10 from anything other than Windows 8 / 8.1 – you probably won’t have this problem.
- If you only ever use one user account; the one you used when you installed or upgraded to Windows 10 – you probably won’t see this problem.
- If you upgrade in place from Windows 8.1 to Windows 10, and if you have more than one user account on your machine, even if you do not use AB Suite – you will almost certainly have this problem with one or more of your alternate user accounts.
For most people in a business environment this may not be a concern, because when you receive a new computer, or upgrade an existing one, it is probably set up by a help desk or tech support team, and they build your system from a standard system image that may have been tailored for your company. On the other hand, if you do your own upgrade, say because you received a notice about the free upgrade from Microsoft, or if you recently bought a computer that came with Windows 8.1 already installed, please be aware.
The problem was not hard to fix, but it was very difficult to diagnose in this case. Kudos and thanks to the Unisys AB Suite engineering team for their perseverance and support in tracking down this problem. Hopefully, since we have identified the problem and its resolution, you won’t have to go through the same frustration we did.
I don’t know if Microsoft has fixed this problem in later updates to Windows 10, but as recently as April 2016 some people still seem to be running into this problem.
As I said, the problem isn’t especially hard to work around, once you know what is happening, and what symptoms to look for, but getting to that point can be very frustrating and time consuming. So I am posting this history so others can benefit from this experience.
RSS Feed
