Updated code to Reversion 23: 
http://code.google.com/p/cryptnos-for-windows/source/detail?r=23

This isn't necessarily a fix, but it does contain a lot more robust error 
checking in both the update checker DLL (which is not included in the project) 
and the main form code that calls it. Since I can't reproduce this error, I may 
need someone to download and compile this to see if it works. (I should be able 
to add a pre-compiled version to the download list upon request.)

Marking this as fixed for now, now that 1.1.1 has been released. We'll see if 
anyone complains about the issue. On my test machine which I keep "clean" of 
development stuff and on which I test installations, version 1.1.0 successfully 
performed the update check, found the new version, downloaded it, and installed 
it. Let's hope this puts this issue to bed.

Problem persists in 1.1.1 on Windows 7 x64. Similar problem presented with 
another application, Avast. In that instance the problem was related to the 
Visual C++ 2008 Redistributable included in that packages installer. I removed 
the x86 version of the redistributable and installed the x64 redistributable in 
the case of Avast. This did not work in the case of Cryptnos, but may lead to 
further discovery.

Additionally the source DL on Google and the homepage results in a corrupt zip 
so I was unable to download and compile manually to try to isolate the problem.

Thanks for the report. Cryptnos uses .NET 2.0, not Visual C++ 2008, so updating 
that particular redistributable shouldn't have an effect. Have you tried the 
x64 version of the .NET 2.0 redistributable? Unfortunately, I don't have a 
64-bit system to test with.

I downloaded the source ZIP from Google, uncompressed it, and successfully 
rebuilt the source from it. The file from the Cryptnos site (www.cryptnos.com) 
has the same SHA-1. Did you check the SHA-1 after the download? Did you try 
downloading it again? What ZIP utility are you using to open it? Have you tried 
checking out the source via SVN?

For anyone still following this, I'm just going to comment out the update 
checker with the move to version 1.2.0. Obviously, something isn't working, and 
I really don't have the time or resources to track it down. I can't reproduce 
it, and I haven't received sufficient feedback from those who can to find out 
what's really going wrong. Thus, pulling out the offending code seems like the 
easiest solution. It was a "nice to have" rather than a critical feature 
anyway, and I don't want to keep anyone from using the program just because a 
bit of bonus code stands in the way.

I completely forgot about this until I received the bug update via email. It 
was my intent to assist and compile the project locally as I can replicate the 
problem with the redistributable, but I never got around to it.

I am still unable to unzip the source using IZArc or Windows Explorer. I have a 
SHA-1 of 92A436E04B6D820147A51FFCDC45258DFA0DD227 matching the 1.1.1 release 
per the Google Code download page, but receive an invalid ZIP message when 
trying to unzip. What compression tool are you using?

I'm using 7zip on Windows, which opens it fine. However, when I pull the ZIP 
down to my Fedora box and try GNU unzip, it doesn't seem to like it either. 
Give me a couple minutes and I'll re-archive and and re-upload the file. (I'll 
have to check the 1.1.1 source branch back out since I've already started work 
on 1.2.0.)

OK, I checked out the 1.1.1 source, re-ZIPped it, and double-checked that I 
could open in with GNU unzip on Fedora. If that can open it, the file should be 
fine. While I was at it, I included the source for the GPFUpdateChecker 
library, which is not in the official SVN repository and not in the original 
source archive either. Since the problem code likely exists in the update 
checker library, it helps to have that source as well. :D

I just got an x86-64 Windows 7 Pro machine and during the process of setting up 
Cryptnos for my own purposes, I managed to get the dreaded "Object reference 
not set to an instance of an object" for the first time. Adding the 
"DisableUpdateCheck" registry key as described in the original issue 
description worked just fine as a workaround; I've been using it without 
problems as long as that key is present.

The good news is that this now means I have a way to reproduce the error and 
thus hopefully a way to fix it. Unfortunately, I'm also have trouble getting MS 
Visual C# 2005 Express installed on that machine; there are a number of 
compatibility issues with respect to Vista/Win7 and VC# 2005. If I can get that 
working, I'll do some debugging and see if I can pinpoint where the error is 
coming from. If not, I'll try moving up to VC# Express 2008 or 2010 and try 
debugging again. I'm not sure how that will affect the project since Cryptnos 
is .NET 2.0 and those are .NET 3.x+, however.

I should also note that I got the error in the current "trunk" build, which is 
1.2.x and which should have the update checker code completely commented out of 
the main application. This means that either the update checker isn't the 
problem after all, or just its mere presence in the project is enough to 
completely blow things up. Another debugging task here will be to remove all 
references to it from the project and try building again. I don't think that 
will fix things, though, since the registry key hack leaves the code intact but 
just skips over the call to the update checker, meaning the code is still 
present but just ignored.

Unfortunately, I've got a lot of irons in the fire at the moment, so working on 
this is something I don't have a lot of time to do. Such are the pitfalls of 
Open Source projects with only one developer, I suppose. Maybe once my day job 
project winds down or I get some down time during the holidays I'll have some 
more time to look into this. Sorry, folks.

OK, folks... for those of you still listening...

I think I've tracked down and squashed the dreaded "Object reference not set to 
an instance of an object" bug in Cryptnos for Windows. It was *NOT* in the 
update checker coded as I previous suspected, but in two places during the core 
start-up routines. The gory details are below, for anyone interested; for those 
who may not be, you can skip everything beyond this paragraph. Suffice it to 
say, I plan to build, test, and release 1.2.0 very soon, perhaps before the end 
of the day. (I want to make sure related changes in Cryptnos for Android are in 
sync so the two are released at the same time.) Since the update checker code 
seems to be A-OK, you should be able to remove the "DisableUpdateCheck" 
registry key as outlined earlier in this thread. (To be extra safe, it might be 
a good idea to update to 1.2.0 before removing this key.)

For those interested, it looks like there were two places where this error was 
being thrown. The first occurs in the very beginning of the program, in the 
file Program.cs, which runs before the code of the main form even gets loaded. 
There's a bit of code that checked to make sure that the version number on the 
currently executing code is the same or later than any version number of any 
previously run version of Cryptnos. The idea behind this check is to warn users 
who might try to "downgrade" that their settings from a later version may not 
be compatible with an earlier version. (Settings *are* forward compatible and 
"upgraded" to the current version the first time a new version is run.) 
Unfortunately, I may have made an incorrect assumption on how the .NET C# 
registry API works when a registry key does not currently exist. I assumed 
something would return null, but instead an exception was thrown. While a 
try/catch block was in place to catch exceptions, it merely echoed the error 
and exited the program. Now it should catch the exception but continue on, 
letting the main body of code, which already had steps in place to deal with 
the situation where the registry keys did not exist, continue.

The other problem was a typo that created a registry key if it did not exist, 
but did not assign that key to a variable. When I then tried to reference the 
variable, it remained null, throwing another instance of this error. This was 
harder to catch because it would be caught in a try/catch but would eventually 
work its way out eventually, as the code gets called several times during the 
life cycle of the app. This didn't generate the symptoms other users reported, 
but was essentially the same bug but in a different place.