I believe I've found the answer to the SE_CREATE_GLOBAL_NAME issue. Whether or 
not this answers the overall problem will require a bit more testing.

Cryptnos uses a small bit of code at start-up to prevent more than one instance 
of the application from running per user. This is a data safety measure; since 
Cryptnos stores all its data in a given registry key under HKCU, having 
multiple instances open at once could result in data corruption. One instance 
of Cryptnos could make a change to the registry that the other instance won't 
see, then the second instance might overwrite the first instance's changes.

To prevent this, Cryptnos uses a mutex (System.Threading.Mutex) to control 
access at start-up. When the first instance opens, it creates the mutex and 
claims ownership, holding on to it until the instance closes. If a second 
instance starts, it will attempt to claim the mutex and will fail. In this 
case, it won't create the main app window but will instead give focus to the 
already open window then silently exit.

The problem is that the initial example I used as a guide used poor practices 
in naming the mutex. That example, and Cryptnos in turn, used a rather generic 
name based on the application's name. This worked relatively well on my 
personal development machine, so it made its way into Cryptnos. Unfortunately, 
neither I nor the original example's author realized that this arbitrary naming 
would give the mutex a global scope.

This is where I think the problem surfaced on my work machine. With the 
restricted permissions enforced by a new corporate policy, I lost many of the 
administrative privileges I still enjoyed on my personal machine. Along with 
this likely went the ability to create and manage globally-scoped mutexes. When 
Cryptnos attempted to run under this tighter security and tried to create a 
global mutex, this caused a security exception. And since I blindly followed 
the original example, the creation of this mutex did not occur in a try/catch 
block, resulting in a crash. I don't think it should have caused the data 
corruption based on the flow of logic in the code, but I can't rule that 
possibility out.

I am making some changes to the Cryptnos code that should change the scope of 
the mutex to being local for the user. This should prevent an individual user 
from launching multiple copies at once, but many users could each run their own 
copy without problems (say, under Terminal Services). I have also improved the 
error handling during start-up, which should greatly decrease the likelihood of 
a crash and data corruption.

I am waiting on feedback from the other reporter of the problem, hoping that 
he'll be able to test the new code on his machine. Once I get some good testing 
in, I'll probably release this as a 1.3.3 patch.

This issue was updated by revision r57.


Tweaked mutex code in main program code to hopefully avoid issues pertaining to 
Issue 8. Still need feedback from the original reporter to have a better idea 
if it works.

Updated the GPFUpdateChecker library with some better error handling and 
reporting.

Cryptnos should now always default to UTF-8 rather than the system default 
encoding if the user hasn't set a preference. While the original behavior 
mimicked the old way of doing things, it's really a Bad Thing(TM) in terms of 
cross-platform interoperability.

Tentatively bumping version number up to 1.3.3.

OK, I haven't heard from the original reporter in some time, so I have no 
confirmation either way that the proposed fix works for him. That said, I can 
report one what's happened on the workstation I use mentioned in the original 
post.

I have been running the tentative 1.3.3 code on this workstation for some time 
now without encountering any loss of data. All site parameters and settings 
have remained intact. This has been somewhat difficult to test, however, since 
the locked down security has prevented some of my tests. Apparently our admins 
systematically remove "unapproved" applications as Cryptnos will no longer run 
if installed via the installer; I can only get it to run by copying the EXE and 
support files into a non-standard location and running it directly. That said, 
it *does* run and the parameters are still in place. I guess I'll take that as 
a good sign.

So I'm going to go ahead and make preparations to push out 1.3.3 as an official 
release, once I'm finished making changes for some other enhancements. I will 
close this issue as fixed once I push that out; if the problem resurfaces, I'll 
reopen this ticket.