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