Compartilhar via


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:

 

System:

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

User:

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 ..

 

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

FileName: CREDHIST

 

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

 

Spat

Comments

  • Anonymous
    November 16, 2009
    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.

  • Anonymous
    November 17, 2009
    Q: I am runnig Win7 and the key  HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders is created by default. The value in Win7 for appdata is : %USERPROFILE%AppDataRoaming 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 spat