application error

[Mehdi.S]

Thank you very much.

It worked. Now I can use v1.4.26 with no problem.

I'm looking forward for new version and hope to solve the problem on my OS.

[merina31]

It's a coincident that i have also face this problem and was really confused for the solution.

[TheAPGuy]

It's a coincident that i have also face this problem and was really confused for the solution.

Do you mean your still having problems?

[gachmuret]

Hi there,

Same error here on Windows 8.1 Enterprise edition... also tried the new beta version... same error.

Could you please post an older version prior to this error (like v.1.4.26 posted above)? Thx a lot!

Log:

Autopatcher v6.1.8 Has Started at 08/04/2014 06:03:57

Starting Autopatcher From C:\Downloads\Apup

Detected OS: English (1033) Microsoft Windows 8.1 Enterprisex64
Current Locale: Arabic / Non-Unicode Default: English
Error Detected: Failed to acquire cryptographic context In HashModule.HashFile At Line 116

[ccentral]

I'm posting this here so that maybe someone can benefit from my efforts over the past two days to debug this issue.

Here's the exact error I was getting every time I launched AutoPatcher on a problematic system:

Where: HashModule.HashFile() At Line 116
Error Code: 0x1: Failed to acquire cryptographic context

In my case, the problem was the Microsoft Cryptography MachineGuid registry value was corrupt.

Important: The following information contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. I cannot guarantee that problems resulting from the incorrect use of the information below can be solved. Use this information at your own risk.

For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, please refer to Microsoft KB Article #322756 (http://support.microsoft.com/kb/322756).

1. Open the Windows Registry Editor. If you don't know how to do this, STOP NOW!
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
3. Double click the MachineGuid value
4. If there are any curly brackets in the value, remove them, e.g.:
   • BEFORE: {4bb3aa61-659e-4eca-8a03-df271932c051}
     AFTER: 4bb3aa61-659e-4eca-8a03-df271932c051
5. Restart the computer and try again

Note: I didn't actually have to restart the computer for the fix to work, but you might want to just to be sure!

[TheAPGuy]

nice detective work. I will make sure to point to this if a similar error happens for someone else.

[ccentral]

ADDENDUM:
(Highly) Technical information for the Autopatcher developers, the curious, and (hopefully) for search engines to lead people with similar issues to the solution!

The symptom of the problem was the CryptAcquireContext API was failing with conflicting errors. Looking at Microsoft's sample, the general approach is to attempt to open an existing container first, and if that fails, create a new one. But here's what was actually happening:

1. Calling CryptAcquireContext with the dwFlags parameter set to 0, to try and open an existing container, would return error 0x80090016 (NTE_BAD_KEYSET, "Keyset does not exist").
2. Calling CryptAcquireContext with the dwFlags parameter set to CRYPT_NEWKEYSET, to try and create a new container, would return error 0x8009000F (NTE_EXISTS, "Object already exists").

See the conflict here? When we try to access the container, it doesn't exist. But if we then try to create the non-existent container, the API now insists it already exists! Catch 22!

My initial investigations had me checking file permissions on the "%appdata%\Microsoft\Crypto\RSA" and "%programdata%\Microsoft\Crypto\RSA" folders, but that led nowhere - the permissions were fine. It was only when I used Process Monitor to compare the problematic system with a known-good system that I noticed the format of the MachineGuid values were different. A quick Google search for "MachineGuid corrupt" confirmed my suspicions, and two seconds of experimentation later - Voila! Problem solved!

Before I go, though, there's another aspect to this whole story that I left out: The errors ONLY occur when using private keys. If you call CryptAcquireContext with the pszContainer parameter set to NULL, and dwFlags to CRYPT_VERIFYCONTEXT, the API returns with no errors - regardless of whether or not the MachineGuid value is corrupt. Without knowing more about how Autopatcher uses the API, though, I don't know if this information actually helps. But if it does, remember me in the credits or something. LOL!

[TheAPGuy]

AP uses the MS crypto API to do hashes on files to verify them.

The following are used this order.

Code: Select all

CryptAcquireContext (here the code does both. Looks for an existing key and if it can't find one, create a new one)

CryptCreateHash (generate hash object)

CryptHashData (feed chunk data in a loop)

CryptGetHashParam (get the generated hash)

CryptDestroyHash (delete the  hash object)

CryptReleaseContext

I will check into that little tip you left some time.

[ccentral]

What I meant to say is that I don't know enough about the Crypto API to say whether or not switching away from private keys is the right answer. In fact, I never really looked at the API until yesterday, and even then it was only enough to create a little C++ app to reproduce the issue simply and reliably enough for debugging purposes.

I do know that the CryptAcquireContext topic on MSDN says:

In particular, a CSP may have a single default container that is shared by all applications accessing the CSP. Therefore, applications must not use the default key container to store private keys. Instead, either prevent key storage by passing the CRYPT_VERIFYCONTEXT flag in the dwFlags parameter, or use an application-specific container that is unlikely to be used by another application.

So if Autopatcher actually needs persisted keys, then the current approach is obviously the correct one. But if you don't need persisted keys, the article goes on to say this (important bit highlighted in red):

For performance reasons, we recommend that you set the pszContainer parameter to NULL and the dwFlags parameter to CRYPT_VERIFYCONTEXT in all situations where you do not require a persisted key. In particular, consider setting the pszContainer parameter to NULL and the dwFlags parameter to CRYPT_VERIFYCONTEXT for the following scenarios:

• You are creating a hash.
• ...

I take this to mean that if all you need is the hash functions, you can just use CRYPT_VERIFYCONTEXT and avoid the issue altogether. But if you do need persisted keys, the next best thing would be to check the return value from the second CryptAcquireContext call (the one using CRYPT_NEWKEYSET). If it returns NTE_EXISTS, you could simply throw up a message telling the user to check the MachineGuid value. Or if you want to get really fancy, you could check the value yourself and alert the user if you have determined that it is invalid. Either way, I'd put the burden of actually fixing the issue on the user. CYA, you know...

But then again, I could certainly be reading the API documentation wrong. You're the expert here, and I will defer to your judgment either way.

[TheAPGuy]

woOOOoo don't go putting expert in front me here. I am by far no expert even if I did get B+'s in my programming classes even in assembly(god the nightmares don't stop), I red the samples a few times and put together the code to switch from using am unknown dll that the project was using that had NO src files or even a way to tell where it came from, to using the MS API. This project is a spare time thing for me. I love the usefulness of the Autopatcher project so I volunteered to help keep it going instead of let to disappear.

Anyways you do put forth a compelling argument and I will put together some test code to see what is what.