I'm still looking into this problem, but to summarize:
I wrote a very simple Windows Service in VB.NET, as part of a larger
application. I created a deployment project for the application the
resulting MSI explicitly installs the service. I've ran the installer
on 4 machines at our office (2 are running Windows 2000 Pro, 1 is
running XP Pro, and the other is running Windows 98). On each of these
machines, the installation goes without a hitch and the application
runs fine (the Windows Service basically runs a timer with a 1-minute
interval -- each minute, it checks a registry value to see whether or
not it should run a particular EXE, using the
System.Diagnostics.Process.Start(string) overload, i.e. it's a very
simple task scheduler so to speak). The service runs great on the 4
previously-mentioned machines, and when it decides it's time to run the
other EXE, it works without a hitch. However, when we installed the
application on a customer's machine (running Windows 2000 pro), the
service runs fine until it comes time to fire off this other EXE. At
that point, an UnhandledException is quietly logged in the Event Log -
the EXE it is supposed to fire off starts and then stops almost
instantaneously. I should note that the EXE which this scheduler
service fires off is a .NET application, and it is in the same
directory as the scheduler service's EXE. The problem is:
a) the message in the Event Log is extremely unhelpful: it amounts to
saying that an UnhandledException occurred and that it (supposedly)
occurred in the EXE which the scheduler service attempts to fire off.
There is no explanation of *what* the exception actually is.
b) the EXE which the scheduler service fires off has a Sub Main as its
startup object. I wrapped all the code in Sub Main in one big
Try...Catch e As Exception block, to provide a quick-and-dirty
"catch-all" mechanism, thinking I could catch this mysterious unhandled
exception. The strange thing is that catching Exception doesn't catch
the unhandled exception!! Do I need to explicitly add an
AppDomain.UnhandledException handler or something similar (I'd try that
now, but I'm not at work) ? In any event, I don't understand how the
exception still goes unhandled, even when I explicitly catch the base
Exception class in Main.
Again, this issue can only be reproduced on our customer's machine (go
figure...) and we've been having a heck of a time seeing what else
could be causing the issue. On that note, we did notice that this app
we're installing shows up twice in the .NET Wizard's "Fix This App"
list of currently-installed managed apps. One entry shows up for the
current version (which is installed to Program Files), and another
entry shows up for an older version of the application (back then it
was also installed to a different directory). The problem here is that
the second entry shouldn't be showing up: the previous version was
completely uninstalled and we can't find any dangling references to it
anywhere, not on the hard drive, not in .config files, not in the
Registry, nowhere...I'm digressing from my original question, but does
anyone know how to remove the duplicate entries and for that matter
*how* that list of managed application is built, i.e. where it pulls
the data from which it builds the list? We think this duplicate entry
issue could be the real problem, since we've encountered this issue
before with other .NET applications.
--
Mike S
