Resolving “PAUTOENR.DLL raised an exception”

This has been nagging me for about a month.  On my personal SBS 2008 box, since mid-October, I have been getting this error repeatedly.  When logged on to the server console, a Windows Error Reporting dialog pops up every minute reporting that Taskeng.exe has stopped working.

Taskeng is the main process of Windows Task Manager, which has a console under Administrative Tools. 

What was causing Task Scheduler to crash?  I very quickly found it—Certificate Services Client was causing it, as you may have seen in the Event Viewer screenshot;  it throws a error message right before Task Scheduler reports the crash.  It has three tasks:  SystemTask, UserTask and UserTask-Roam.  On my machine, SystemTask was crashing and trying to restart.  That accounted for the repeating WER dialogs.

But what is the Certificate Services Client?  What do its three tasks do?

The Certificate Services Client (CSC, not to be confused with Client-Side Caching) is a component of Windows that allows users to use their site certificates, which are often used for VPN, email authentication and many other services on a corporate network.  It’s been a part of Windows for awhile, and it’s on Windows Server 2008 and by extension SBS 2008.

A very important part of the CSC is autoenrollment:  Autoenrollment is the process of keeping track of user certificates, expiring them and renewing them as needed.  PAUTOENR.DLL is the DLL that manages this process, running with DIMSJOB.DLL and DIMSROAM.DLL under Task Scheduler.

After a lot of tracing with Process Monitor and a lot of research online, I have a conclusion:  The CSC, and the Autoenrollment feature, each keep a cache of certificate information.  It was corrupted.   I suspect a certificate expired sometime in October or a bit before, and the Autoenrollment choked on it.

I must note at this point that the CSC is a client.  On an SBS machine, it runs alongside the Certificate Services role, but it is totally separate so it does no good to troubleshoot Cert Services if it is otherwise working.  Don’t touch Cert Services.

This is an involved process with several reboots so you will need patience.

  1. First, pull up Task Scheduler from Administrative Tools.  Select “Task Scheduler Library” and open Microsoft\Windows\CertificateServicesClient.   We are going to disable each of the three tasks before we delete the cache.  On each task, SystemTask, UserTask and UserTask-Roam, right-click and select End.  Repeat this for each task and select Disabled.
  2. Follow these steps to delete the certificate cache on the server:  Go to the LOCAL SYSTEM profile at C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache.  Copy the CryptNetURLCache folder to a safe place.  Two folders are there—Content and Metadata.   Go to each folder and delete the files therein—don’t delete the Content and Metadata folders themselves.
  3. Run Regedit as an administrator and go to this key, HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\AuthRoot\Certificates.  Delete all the keys under this key.   That takes care of the certificate cache.
  4. Now, delete the Autoenrollment cache.  Go to Regedit and to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache.  Delete all the keys under that key.
  5. Go back to Task Scheduler.  Open the CertificateServicesClient folder that we had opened before (Task Scheduler Library\Microsoft\Windows\CertificateServicesClient).  Right-click on each task and select “Enable”.
  6. We aren’t done yet.  The Certificate caches have been empty, but they need to be repopulated.  To do this, we need to change the local security policy on the machine to turn on autoenrollment temporarily until the caches are repopulated.  By default (on my SBS box at least), autoenrollment is not turned on.  This is often done on Windows networks via the Default Domain policy but I am really uneasy about making a global change to fix a local problem so the local security policy is the best way.
  7. Open secpol.msc as an administrator to access the local security policy.  Click on Public Key Policies.  On the right pane, double-click Certificate Services Client—Auto-Enrollment Policies.  In the dialog, click on the Configuration Model dropdown box and select Enabled.  There are two checkboxes:  Check both boxes, “Renew expired certificates, update pending certificates and remove revoked certificates” and “Update certificates that use certificate templates”.  Click OK.
  8. From an elevated command prompt, enter the command gpupdate /force to make the change apply to the machine.
  9. Restart the server.
  10. Log back on and reopen the Task Scheduler and the CertificateServicesClient task.  SystemTask and UserTask will show as running.  Click on SystemTask, and click the History tab.  The most recent events in History should show that the task started normally and is currently running.
  11. While still on the SystemTask window, right-click and select End.  This task normally only runs when the system is restarted, and every eight hours thereafter.
  12. Next, we will undo our changes to the local security policy.  Open secpol.msc as an administrator and select Public Key Policies.  Click on Certificate Services Client—Auto-Enrollment Policies.  On the Configuration Model dropdown box, select “Not Configured” and click OK.
  13. From an elevated command prompt, reenter gpupdate /force to undo the change.
  14. Restart the server again.
  15. Log back on once again and reopen the CertificateServicesClient task.  SystemTask should be listed as Ready or Running.  UserTask should be Running.  UserTask-Roam should be Ready.  Look at the event history for each task.  If there are no errors since the last reboot, the problem is resolved.  You may want to try running the SystemTask as a test, if it is not already running.

16 Comments on “Resolving “PAUTOENR.DLL raised an exception””

  1. Thanks for the detailed article. It was very helpful. However I noticed one path was incorrect. It should be C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache

  2. mp says:


    Have you not encountered similiar problem to yours? – it appears only in event logs but it is still bothering me. I have applied steps you desribed here but nothing changed. Here are error details:

    TaskScheduler 101
    Event Details:
    Task Scheduler failed to start “\Microsoft\Windows\CertificateServicesClient\UserTask” task for user “domain\domainadmin”. Additional Data: Error Value: 2147942402.
    followed by another error:

    TaskScheduler 311
    Event Details:
    Task Scheduler failed to start Task Engine “” process due to an error occurring in “LUAIsElevatedToken” . Command=”taskeng.exe” . Additional Data: Error Value: 2147942402.

    Thank you very much

  3. computer_bob says:

    Looks like it did the trick, thanks! Been looking for a resolution for this issue for months.

  4. Marcel Brabetz says:

    Does step 2,3,4 delete the local installed certificates? (e.g. buyed certificates from public CA)

  5. Cosmin says:

    After doing everything as specified above the SystemTask was on queued. When I manually tried to “Run” it, it failed and returned this in the “History”:

    Task Scheduler failed to execute task “\Microsoft\Windows\CertificateServicesClient\SystemTask” . Attempting to restart.
    Additional Data: Error Value: 2147943467.

    Event Viewer still shows up the errors…

    Please advise!

  6. khirx says:

    After all those steps, it didn’t help for me. BUT I changed the account on which the SystemTask runs from System to our domain administrator-account and to run with Highest priviledges and now the task is running well.

    • davidcmoisan says:

      Glad it works, but it has to be abnormal. Local System should not have a problem with that. It’ll likely work fine until you decommission the server, but you’re the first I’ve heard of that has had to do that.

      • Gil says:

        Yep, khirx’s solution helped me. I’ve been getting error messages for months about the SystemTask, to the point where I stopped closing the dialog box so that it wouldn’t pop up again, but as soon as I changed the user to the domain administrator, and used “run with highest privileges”, the error disappeared, and the task appeared in my “Running” tasks” dialog box!!! Thanks, David and khirx!

    • James Newton says:

      That also worked for me, without doing any of the steps above.

  7. TK says:

    It seems that this instruction also worked for my case. I also saw an error in the task history but this was a one time effect. Now the system runs since 7 days without incident. Thanks very much!
    I am only wondering what was the purpose of copying the contents of C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache
    To a save place?!

  8. Minakovic says:

    Well I also had the error when trying to reschedule a Job (trigger One time) Windows 2008 R2

    Initial Error Message comming from the task scheduler was :
    The following error was reported: The referenced account is currently locked out and may not be logged on to..

    In the event view for TaskScheduler I had 2 errors:

    Task Scheduler failed to start “\Microsoft\Windows\CertificateServicesClient\UserTask” task for user “username”. Additional Data: Error Value: 2147942402.

    Task Scheduler failed to start Task Engine “” process due to an error occurring in “LUAIsElevatedToken” . Command=”taskeng.exe” . Additional Data: Error Value: 2147942402.

    The user in question was disconnected for many days, no schedule task created or running under this user and account was not locked, I logged off the user, still had the issue.

    What I did to solve it:
    First when to my task, I changed the User or Groups under the General tab
    Selected Run only When user is logged on then click on OK
    After that I was able to reschedule my job.
    Put back Run whether user is logged on or not.
    everything is now back to normal.

    Hope this helps

  9. Hannes Dorn says:

    Thanks, you saved me and my client a lot of time.

  10. GB says:


  11. Oz Solomon says:

    David, thanks for this great article, it was a lifesaver.

    I’d like to tell anyone planning on performing these steps that for me at step 9 I was hit by the problem in this KB:

  12. Stephan Joe says:


    thank you very much! You took a away a very big problem from me and the company I am working for.

    Warm regards,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s