Has anyone else had problems with the Application.DoEvents statement? I have a VB.net written DLL that throws the ubiquitous "Object reference not set..." error on a couple of machines. I can't duplicate the error on my desk or on other machines. When I put code in to trace down exactly which statement it's on when the error hits, it's a DoEvents statement. I mostly put those in to give the calling apps time to process other events, so they aren't all critical. So, in an attempt to narrow it down, I removed the offending statement. The error hit again but this time on the next DoEvents statement it found in the code. This has got me completely puzzled. Normally, when something happens on one machine and not one all, I check to make sure any referenced DLL's are the same. They are. This DLL calls 2 COM objects and 1 .NET DLL and all of those references are identical in version. I know the error normally means that someone forgot a "NEW" statement or an object was inadvertantly set to Nothing, but I can't find any object where that would make sense. If that was the case, the DLL wouldn't run cleanly anywhere, but it does run OK on some machines, including in the development environment. Any ideas would be greatly appreciated.

In VB, the command line parameters are read from a function (like "Command"). They are not passed into the Main as parameters. Remove the parameter from Sub Main and re-code it to read the parameter from the Command function and you should be all set. Mike Mestemaker

In some of our larger applications (VB.NET), we keep getting an application exception as the program is shutting down. This seems to be untraceable, but maybe I'm missing something. Here's what the message says: [ProgramName.exe - Common Language Runtime Debugging Services] Application has generated an exception that could not be handled. Process id=0xa6c (2668), Thread id=0x9f8 (2552) Click OK to terminate the application. Click CANCEL to debug the application. Here are the facts we know: 1. Never happens in development mode (when debugging in the IDE). 2. The process ID and thread ID's I mentioned above vary. 3. Is somewhat random, but occurs more often than not. 4. Always occurs during the shutdown of the application. 5. When I place tracing statements in the code to write out messages to a text file so I can determine which line of code is blowing, it's always on or after the END statement. 6. There appears to be NO negative result on the data or the operating system after we acknowledge the error. 7. The error is definitely NOT coming from any error handler I've got in place; I'm assuming it's generated by the .NET framework. 8. It usually seems to happen on machines that don't have any debugging tools, so clicking on CANCEL doesn't really do anything. I got it once on a machine that had the .NET IDE loaded on it; clicking cancel just told me there was no code at that point that could be debugged. The other day, the application that does this the most did something slightly different when it ended, but the effect was the same. This occurred once and has never duplicated, so it might be a red herring. This time the message box said: [WindowsFormsParkingWindow: ProgramName.exe - Application Error] The instruction at "0x77fcc813" referenced memory at "0x00000010". The memory could not be "read". Click on OK to terminate the program. Does anyone have any ideas or clues on how to start finding and eliminating this? While it doesn't seem to hurt anything, it sure does make it look like my app is broken to the customer. Thanks for any help. Mike Mestemaker

One trick I've been using is to put most of the initialization code in a one-shot timer (.AutoReset=False) and set the interval on that timer for something like 30-45 seconds. That gives you the time to connect the debugger to your service before that code starts. Since my service is based around another timer, I just leave my main timer disabled until the initialization timer fires. Put your first breakpoint in the initialization timer and you can then debug that code. Once you are happy with your initialization code, you can speed things up by changing the initialization timer's interval to something much shorter. Don't change the structure for production, just shorten the interval. If you need to re-debug something in the init code, you only have to change your interval again.

Thanks for the advice. Let me see if I understand the basic concept: At the beginning of the processing section that I want to be "uninterruptible": Try    Dim M As New Threading.Mutex(True, "myUniqueCode")    ' do the processing Finally    M.Close() End Try In the OnStop event Dim M As New Threading.Mutex(True, "myUniqueCode") Do Until M.WaitOne(1000, False) Loop M.Close() 'do any resource cleanup here Related question: What is the correct way to shut down my service from within it's own code? For example, if my service encounters a condition that tells it to end (other than the SCM's stop command), how does it shut itself down cleanly? I read somewhere that the END command is considered bad form for services. Long term, my application will consist of multiple services (each with their own uninterruptable sections). Some will be more sensitive to this issue than others. I'm thinking of creating an applet that will send a message to each of them and they will shut themselves down when they are free from whatever they were doing). The applet can show the status of each one in turn so the user can watch them shutting down and know when it is safe to proceed.

I'm building a Service in VB.NET: It's basically watching for a file to appear in a directory; when it does, it processes that file into a database. Depending on the size of the data file, this process can take some time. What I want to be able to do is prevent the Service Control Manager (SCM) from shutting my service down while it's busy. What is the best way to do this? I tried setting Me.CanStop to false on the fly, but found that it can't be changed while the service is running. :( The one idea I've had so far is to create a boolean called isBusy that is set to true while processing and false while idle. Then, in the OnStop event do the following to prevent the stop until the task is done:

Do While isBusy
DoEvents
Loop

But, then what happens when this exceeds the timeout that the SCM has? The SCM reports an error, but does the service eventually shutdown? My main concern is finding a way for my user to shut the service down without shutting down in the middle of a task. :confused: Thanks for any insight.