The case of the Ghostly Apparitions

[ThermoSight]

This thread might be more appropriately titled "The case of the Shadowy Process"

I have a C# application (running Visual Studio 2008 (version 9.0.21022.8) .NET (version 3.5 SP1) on a VISTA system) which appears to be running satisfactorily, but it's important to disclose that I DO update the source frequently, almost daily.

Recently a problem has crept into view which SEEMS to be associated with a 'release' build exclusively; that is, I haven't YET seen it with the 'debug' build.

Here's the problem .....

When I first start the program, the program DOES begin, but the initial form which should appear immediately, does not appear. Doesn't matter HOW long one waits, that first form never appears. However, opening the task manager and viewing the list of processes shows that the program's running.

At this point, the 'shadow' process (the program which is running) isn't doing much .... it's sitting there waiting for the user to issue a command through the non-visible form, and, POSSIBLY, it's marking time (literally .... a timer is set to a coming event unless there are no events or the event is too far in the future (more than a week)).

Now, if the user invokes a SECOND instance of the program (clicks on "Start Debuggin" or "Start without debugging") while the first continues to run (invisibly), then THAT form, from the second process, does appear immediately as it should and operates normally ... accepting and acting on user commands issued via the form controls.

At some point, the user will bring down the second instantiation, but the shadow process continues to run ... it still appears in the list of processes. If one attempts to change the source and rebuild, the source compiles just fine but the build fails because the *.exe file is still held inviolable by the 'shadow' process which continues to run, invisibly.

Look all you wish, move windows around, look under the rugs, check out the task bar, do whatever you wish; you will N O T see the form associated with the shadow process, but make no mistake, that process is running and must be shut down with the task manager before one may have a successful build.

I have not yet seen a 'debug' build exhibit this behavior. Debug builds SEEM to work as expected.

So, anyone have any idea as to what I may have done to cause this "first executable don't work" problem?

Also, I should point out that I am not sophisticated enuf to go deep into the bowels of VS 2008 (or even VS 1954) and throw a "create shadow process" switch somewhere, so this is not a result of an option I knowingly selected, but it's certainly possible that I did something inadvertently.

Any suggestion you can offer would be greatly appreciated.

thanks.

OldFool

[dglienna]

Hard to guess, but sounds like you start a process without credentials.

Post some code, and more details, if you can...

[ThermoSight]

Hello again, D (if I may be so bold as to address you by your first initial) .....

Forgive me for disappearing for so long, I was dragged off to fight another fire, but I have returned to this problem which is far more interesting.

Uhhhh, re posting the code, I have no problem with that, but there's quite a bit of it .... do you think I should post the entire app or can you suggest the files most likely to be of interest ? I was thinking of posting the Main Program (which I NEVER even examine let alone modify - honestly, I have not Clue One as to what's in there!) and maybe Form1.cs.

Form1, incidentally, is the main form - the one that, in 'RELEASE' mode, doesn't appear UNLESS there's already a process running.

Please permit me to explain the problem again - maybe I'll explain it in a more understandable fashion ....

I have a C# .NET app which, up until a few days ago, I built and executed exclusively in 'Debug' mode.

In 'Debug' mode, the app always runs and the form always appears on the screen. The app runs normally, all is well.

In 'Release' mode, the app always runs B U T the main form (Form1) DOES NOT appear on the screen UNLESS this is the second instantiation - that is unless there is already a previous version of the app running.

Isn't that bizarre ?


So, let's say we're starting in 'Release' mode with a clean slate from having rebooted the machine. I click on "Start Debugging" OR "STart without breakpoints" (or whatever that button says), and Voila ! N O T H I N G !

The process IS running, I know because the task Manager tells me so, but the Form is nowhere to be found - look wherever you wish, the form is in hiding even though the process IS running according to Task Manager.

Let the process run, but click on either 'Start..." button again and Voila ! the second process is running AND a Form1 is now clearly visible. The user interacts with the form and the program operates normally .... all's well with the world.

Shut down the second process instantiation. Now again initiate a new second instantiation by clicking either 'start' button, and we're still Good To Go. That first instantiation, which is still running but we can't see, is enuf to satisfy the second instantiation, and the second form1 appears on the screen.

Now bring down the second instantiation. Then use the task Manager to stop the first Instantiation.

We're back to a clean slate ... no process running.

Now click on either 'Start' button and as before, the task manager informs us that the process is running, but the Form is nowhere to be found - the user cannot interact with the app 'cuz the form's out ta lunch. The user must call for a second instantiation before a form1 is visible and user-accessible.

So, ... What up wit' dat ?

Since it's the same source in either mode, my guess is that it's something I've inadvertently done to the project settings, but I sure don't SEE anything different (but then again, I'm completely ignorant when it comes to .NET - I use it frequently, but I haven't Clue One re .NET internals / options / commands).

Any ideas what I may have screwed up that would cause the app to require that ghostly first process to be running before successive instantiations will display THEIR form?

Incidentally, I just signed up for a .NET course at UW-Seattle .... the instructor can look forward to a continuous hassle until this issue is resolved.

Thanks for your help.

OldFool

[dglienna]

Did you read what I said? Are you reading or writing anything when the program starts? Is it looking for a config file in the wrong location? Try to repair VS o see if that helps.

We're not going to look at your whole program, so don't post it. If you do post sections that are SHORT, then we can see what you're trying to do.

[ThermoSight]

"Are you reading or writing anything when the program starts? Is it looking for a config file in the wrong location?"


Hello again, D.

Nope. Nothing occurs upon program initiation other than displaying the form and awaiting user-interaction.


No files are sought; no calculations are made; no external devices are accessed .... nuttin'; it's just sittin' there waiting for user interaction with the form (which may or may not appear on the screen depending on whether a previous process is running or not). Incidentally, I would expect that if the problem was something of the sort you suggest (missing file, read/write problem), that
a) the file would still be missing on the second instantiation, and
b) the file would still be missing in 'Debug' mode as well,
but neither has been the case to date.

My guess is that my next step should be to try to determine what could prevent a form from appearing, even though the program is running. (Now that I think about it, Task Manager tells me the process is running .... it doesn't tell me what it's doing. Perhaps it's looping somewhere prior to initializing my app, or even in the middle of initializing the Form, but prior to displaying it). My gut suggests that this is probably not a coding issue ... probably something more like a project setting gone awry.

In fact, while typing that last sentence, it occurred to me that my next step should be to set a breakpoint at the point where the Form is initialized to see if I'm ever getting there - I haven't tried that. Maybe the app isn't even getting that far.

In other words, perhaps I should just settle in for the night and begin debugging the darn problem rather than spending days typing about it - I just thought someone here might have seen this before and know right off the top o' their head what to look for.

Apparently not.

OK, well, I won't bother you again with this .... I've been debugging programs for 35+ years, I can probably figure this one out, too ... it's programming, not brain surgery.

Please, my friend, pardon me while I slip away to engage this problem, hand-to-hand.

Best wishes.

bill

[dglienna]

I'm guessing that when it opens, it looks for a file, and by default writes it in the proper location. Perhaps it doesn't save it, but has it in memory?

It works after that.

[ThermoSight]

OK, D ...

I'll keep you posted, but I should mention that it's likely to be a week before I get any time on this problem. I leave for Boston Tuesday, 26 May, returning the following Monday, 1 June.

I'm bringing only my netbook (and my ever-faithful HP calculator) with me. It's not clear to me that the li'l Acer netbook has enuf gumption to run Visual Studio but I might give it a try. So it could be as much as a week before I can look into this problem.

Regardless of the VS situation, though, I am bringing both apps to Boston (I also have an earlier, C++ version which runs well, but this new, C# version is significantly more ambitious and claims to do more).

Perhaps I can get VS 2008 running on the netbook which would give me a couple of hours each night to debug the problem. If not, at least I'll have a week to test the app.

In any event, if (when) I learn something about the problem, I'll pass the info along to you. I very much appreciate the help you've provided and the interest you've shown.

Best wishes.

bill