The Windows Process Activation Service (WAS) will not start on my Windows 10 PC anymore. As a result, IIS won't start. I'm not quite sure when it happened, but likely in the last month.

During startup, I now get a series of 4 error events in the System log:

WAS 5215: The Windows Process Activation Service (WAS) failed to execute initialization for offline setup. The data field contains the error number. [Data field: 50000780]

WAS 5005: Windows Process Activation Service (WAS) is stopping because it encountered an error. The data field contains the error number. [Data field: 50000780]

Service Control Manager 7023: The WAS service terminated with the following error: The file exists.

Service Control Manager 7001: The W3SVC service depends on the WAS service which failed to start because of the following error: The file exists.

I've not many references to this type of error with the error the file exists.

(I've tried to use ProcMon to try to identify what file it is referring to, but it absolutely refuses to run.)

Edit... finally got ProcMon to work (after extracting the 64-bit version using VS2017). Turns out that the file that was cause the above problem was the "applicationhost.config.tmp" file in the C:\Windows\System32\inetsrv\Config folder. Removing that file allowed the process to continue further.

Now, the first and third errors are:

WAS 5215: The Windows Process Activation Service (WAS) failed to execute initialization for offline setup. The data field contains the error number. [Data field: 0D000780]

Service Control Manager 7023: The Windows Process Activation Service service terminated with the following error: The data is invalid.

As per the answer by Yanbing Shi, here are the most recent lines from the iis.log file:

[01/13/2018 23:10:41] [ ***** IIS 10.0 Component Based Setup ***** ] [01/13/2018 23:10:41] .\inetsrv\iissetup.exe /install SharedLibraries /nano [01/13/2018 23:10:41] Setting Installation Type to Nano [01/13/2018 23:10:41] Successfully added IIS_IUSRS ACE to DACL at %ProgramData%\Microsoft\Windows\WER\ReportQueue. [01/13/2018 23:10:42] < !!FAIL!! > Failed to create the NetFrameworkConfigurationKey key container (result=0x8009000f) [01/13/2018 23:10:42] < !!FAIL!! > Install of component SharedLibraries result=0x8009000f [01/13/2018 23:10:42] < !!FAIL!! > COMPONENT::ExecuteCommand result=0x8009000f [01/13/2018 23:10:42] [ End of IIS 10.0 Component Based Setup ]

In response to Yanbing Shi's next answer...

At first, I was unable to view/edit/delete the d6d986f09a1ee04e24c949879fdb506c_* file. When I attempted to view its permission, I got the message: You do not have permission to view this object's security properties, even as an administrative user. I was, however, able to change ownership to "Administrators" then give that groups Full permission to it, and then I could view it. The file was not a text file but about 28 bytes into the file is NetFrameworkConfigurationKey. I moved the file out of that folder.

I then ran net start was and got System error 80 has occurred. The file exists.

There was nothing added to the iis.log file but the usual Error events were added to the System event log.

I then manually deleted the applicationhost.config.tmp file and ran net start was. This time, I got System error 13 has occurred. The data is invalid.

This time, there were new entries to iis.log

[03/18/2018 07:44:54] [ ***** IIS 10.0 Component Based Setup ***** ] [03/18/2018 07:44:54] .\inetsrv\iissetup.exe /install SharedLibraries /nano [03/18/2018 07:44:54] Setting Installation Type to Nano [03/18/2018 07:44:55] Successfully added IIS_IUSRS ACE to DACL at %ProgramData%\Microsoft\Windows\WER\ReportQueue. [03/18/2018 07:44:55] Created NetFrameworkConfigurationKey key containter [03/18/2018 07:44:56] Created NetFrameworkConfigurationKey user key [03/18/2018 07:44:56] Set ACLs on NetFrameworkConfigurationKey [03/18/2018 07:44:56] < !!FAIL!! > Failed to create the iisWasKey key container (result=0x8009000f) [03/18/2018 07:44:56] < !!FAIL!! > Install of component SharedLibraries result=0x8009000f [03/18/2018 07:44:56] < !!FAIL!! > COMPONENT::ExecuteCommand result=0x8009000f [03/18/2018 07:44:56] [ End of IIS 10.0 Component Based Setup ]


6 Answers 6


The failure happened because WAS could not access the machine keys during startup. Upon first start after upgrade, WAS will try to create new machine keys if there isn't any, or query the old machine keys left from the old OS. In this case, there are old machine keys exist but WAS unfortunately cannot access them for some unclear reason. These machine keys are used to encrypt sensitive information in applicationHost.config or web.config (e.g. user password). WAS will not be able to start if there is no machine key it can use.

The following steps of deleting several machine keys used by IIS might help to allow WAS to start - WAS will simply recreate these keys upon start.

  1. Go to your RSA machine keys folder: C:\Users\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
  2. Find a machine key (file) whose name starts with d6d986f09a1ee04e24c949879fdb506c_*. If you open it using notepad, you should see plain text "NetFrameworkConfigurationKey".
  3. Backup this file to some other folder.
  4. Delete this file.
  5. Following the same steps as 2-4 to backup and delete iisWasKey: 76944fb33636aeddb9590521c2e8815a_*
  6. Following the same steps as 2-4 to backup and delete iisConfigurationKey: 6de9cb26d2b98c01ec4e9e8b34824aa2_*
  7. Manually start WAS
    • Open a command prompt through "run as administrator".
    • net start was
  • Thanks, @yanbing-shi. Please see my responses in the question. Mar 18, 2018 at 13:42
  • We made some progress - at least NetFrameworkConfigurationKey was successfully created. I updated the answer with additional steps. Mar 18, 2018 at 19:06
  • Glad the workaround unblocks you. But the root cause isn't clear yet. Definitely something related to the machine keys was messed up during the upgrade (and IIS has no control on it). The old machine keys were created by WAS before the upgrade, and Windows upgrade carries these keys to the new OS. However, it is completely unexpected that WAS running under SYSTEM account would fail to access the machine keys previously created by itself. Mar 20, 2018 at 6:39
  • If you followed my workaround steps and backup the three old RSA machine keys (1) NetFrameworkConfigurationKey (2) iisWasKey (3) iisConfigurationKey. I would appreciate if you could provide me the following info: If you compare each old key (the backup) with the new one recreated by WAS, do they have the same file name - e.g. whether the "*" part (GUID) are the same? Mar 20, 2018 at 6:39
  • @YanbingShi this solved my problem, thank you. To answer your question, the new keys recreated had the same name as before. I had to change the permissions of the key files to move them. I already had permission but to delete then I had to specifically make them sharable, i.e. right click > give access to and then click on share
    – Swagata
    May 28, 2018 at 22:41

For me this started after running Windows Update yesterday. Installed updates since then:

  • Feature update to Windows 10, version 1709
  • Update for Windows 10 KB4041994
  • 2018-01 Cumulative Update KB4056892

Starting the Windows Process Activation Service (WAS) yielded this error:

Error 13: The data is invalid.

From the System event log:

The Windows Process Activation Service (WAS) failed to execute initialization for offline setup. The data field contains the error number [8007000D].

No idea what was happening. I verfied my administration.config, applicationHost.config and redirection.config contained the expected data.

I tried reverting to automatically backed up configuration files from C:\inetpub\history, to no result.

In the end I took those steps:

  1. Backup all configuration files from C:\Windows\System32\inetsrv\Config.

  2. Deleted everything HTTP related by unchecking the following from Windows Features (do take a screenshot of which ones are installed so you can easily reinstall the same modules afterwards):

    • Under .NET Framework 3.5, don't uncheck the Framework itself:
      • WCF HTTP Activation
      • WCF Non-HTTP Activation
    • .NET Framework 4.7 Advanced Services
    • IIS
    • IIS Hostable Web Core
    • Windows Process Activation Service
  3. Reboot.

  4. Deleted the remaining contents from C:\Windows\System32\inetsrv.
  5. Reinstall all uninstalled features from above.
  6. Reinstall the URL Rewrite Module
  7. Carefully put back the relevant elements from under the <applicationPools> and <sites> elements from the backed up applicationHost.config into the newly created C:\Windows\System32\inetsrv\Config\applicationHost.config.
  8. Execute an iisreset from an elevated command prompt just to be sure.

And hurray, all my development sites are up again.

After this I compared the backed up and new applicationHost.config files and could not spot any major differences. In fact, when I dropped the backed up applicationHost.config into the Config directory and running another iisreset everything still worked, so I guess it wasn't that file causing the trouble after all.

  • I'm glad you were able to get past the issue. I've previously done most of this, but if nothing shows up soon, I may do it again, following your path more carefully. In the meantime, I was able to switch my development to use IIS Express rather than IIS and that works for now. Jan 14, 2018 at 0:56
  • ******** DO NOT FOLLOW THIS ADVISE ********. VERY VERY BAD. Set me a day behind in work. REALLY BAD ADVICE. Once you uninstall .NET 3.5 you cannot reinstall it without a lot of work. I'm just glad I found the following post to fix what happened by following the above instructions. damirscorner.com/blog/posts/…
    – Fractal
    Feb 12, 2019 at 15:26

This happened to me as well after a recent Windows update. Turning off and then turning on the Windows Process Activation Service in Windows Features did the trick for me. Turning this service off will also turn off the following features which you'll have turn back on as well:

  • Windows Communication Foundation Non-HTTP Activation
  • TCP Activation
  • Named Pipe Activation
  • Message Queuing (MSMQ) Activation
  • 1
    Turning off WPAS (Configuration APIs and Process Model were on) and then turning them on didn't help in this case. Jan 14, 2018 at 6:19

Could you do the following checks

  1. Check whether you have this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters\NanoSetup

I believe it should exist if you hit such WAS startup failure.

  1. Check whether you have a file named applicationhost.config.tmp under C:\windows\system32\inetsrv\config (the folder where your applicationHost.config sits).

This temporary file should exist as well to hit such failure.

  1. Open iis.log in c:\windows, scroll down to the end of the file, and search the most recent errors in the log. We appreciate if you could paste any error log message here.

Now I suspect you will see errors in iis.log. Could you paste the errors here to narrow down the cause?


My issue (may not be yours) was that there was bad XML in the machine.config file.

If you've just edited the machine.config, and WAS (and IIS) won't start, it's because of this.


open regedit. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WAS\Parameters Change value of GenerationKeys from 1 to 0. restart all services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.