Registry entry preventing .NET from starting

[Victor]

I've come across a situation that prevents my .net from starting. Let me
start by saying that my app runs fine with no problems. Then I installed
Time & Expenses from a company called Cyncware. After installing this app
my application no longer booted. After some analysis I find that no .NET
apps run. I compared my registry to the original registry before the
Cyncware was installed and I found that
HKEY_LOCAL_MACHINE\Comm\Security\Crypto\Defaults\Provider\Microsoft Enhanced
Cryptographic Provider v1.0 has a key called 'Signature' and its value was
changed. So I changed it back to the original value and my .NET apps run
again. However Time & Expenses now complains that Visual Basic runtimes are
not installed.

I'm not familure with Cryptographic so I have no clue how this Registry key
is used. The key value is very long so having someone manually re-enter it
is not a good idea.

My product is a commercial application so I can't tell my customers what
they can and cannot install on their devices. On my device I just don't use
Cyncware products (although this issue is not their fault).

Oh by the way, I'm testing on a Windows Mobile 2003 device. My 2002 device
ignores the value in this Registry key (I completely blanked it out, did a
soft reset and it still ran).

Thanks in advance for any help you can provide.

 

[Pavel Treskunov [MSFT]]

Victor,

This is only an educated guess, based in the information you have provided.

The behavior that you are observing is most likely caused by the following
chain of events:
1. The original dll containing "Microsoft Enhanced Cryptographic Provider
v1.0" was replaced (perhaps as a result of installation of some software).
According to
http://msdn.microsoft.com/library/en-us/wcecrypt/html/coconcryptographyregis
trykeys.asp, the signature field "specifies the digital signature", which
means that every CSP (Cryptographic Service Provider) is "digitally signed"
and it's signature is stored in "Signature" field for that provider.
(Changed signature most likely signifies the change of CSP)
2. The "replacement" CSP somehow is incompatible (lack of cryptographic
algorithms, available key sizes, etc.) with the requirements of .NET
Compact Framework, which in turn causes .NET applications to fail.

I would suggest contacting the provider/installer of the "replacement" CSP,
since replacement of CSP may/will have device wide consequences.

Pavel Treskunov
.NET Compact Framework
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------