Crypt* calls failing?

Common crypto issue..


I have seen this more than once so I thought I would mention it here.


Calls to CryptProtectData   or CryptUnprotectData  fail with ERROR_FILE_NOT_FOUND or  other crypto calls fail either in context of the user or the system.  Part of tshooting this should be to  check the following reg paths:



HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders


Specifically – the AppData value should read %USERPROFILE%\Application Data


If this value is bad or the value is missing, all kinds of odd things fail due to the process not being able to determine where key data is, or sometimes the system will fail to find needed data under:

\system32\config\systemprofile\Application Data\Microsoft\CryptnetUrlCache


A bit obscure .. but maybe it will help someone someday..

The hard part is.. how do you know a crypto call is failing since there are very few logs or events?


[Added May 10 ]


One more I ran into  recently ..


"C:\Documents and Settings\JoeUser\Application Data\Microsoft\Protect\



Check the permissions AND the file attributes - should be writeable  ( not read only )



Comments (2)

  1. Q says:

    HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders

    What is supposed to create this key, if anything?

    As I understand it, this key is essentially obsolete, and the crypto functionality should be calling SHGetSpecialFolderLocation.

  2. SpatDSG says:


    I am runnig Win7 and the key  HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders

    is created by default. The value in Win7 for appdata is :


    The API you mentioned , I have not verified, but I would bet CSIDL_APPDATA queries this reg key for the appdata value.

    Easy test , change the value and call SHGetSpecialFolderLocation to verify the return is the same  as your reg edit


Skip to main content