finding and killing an errant process

[Gary Peek]

When I compile a program that has certain "issues" I sometimes get the message, "destination file write error" if the program has been run before and there is some process still running because of the issue. Usually I can find it in the Task Manager, and sometimes using an application killer program, but how can I kill the process if I can't find it?

[Chris Holbrook]

Try closing the PB IDE?

[Gary Peek]

Try closing the PB IDE?

Oh, yeh, I tried that long ago.

To anyone else that is interested, the problem seems to be that my serial port was acting up!

I tried using some terminal programs and the error message from them was that it could not open Com1 (but could open Com2).

I hadn't cleaned the computer for a while, so I blew out the dust, reseated the plug-in cards, and now the problem (seems to have) gone away.

Now what on earth can a piece of hardware like the serial port do that can act like a process that has not been stopped?

And why would the PB compiler say, "destination file write error"?

[Cliff Nichols]

Gary....not likely the port, but the process accessing it (or possibly to a further extent a anti-spyware trying to watch and catch a spyware)

what is the errant process? (since you mentioned serial ports, my interest is peaked)

[Gary Peek]

Gary....not likely the port, but the process accessing it (or possibly to a further extent a anti-spyware trying to watch and catch a spyware)

what is the errant process? (since you mentioned serial ports, my interest is peaked)

I have no idea what the process is because it doesn't show up in Task Manager or the application killer. It must have something to do with the serial port not working correctly. It's working now after re-seating the board.

[Cliff Nichols]

Ok this is a doozy hail mary that I found in the past, that a user claimed my software would shut down windows as if I had gone to the start menu to tell it to shut down.

I knew that Could NOT happen, because I have no shutdown code in the program. So I did some digging, and found that although they had no UPS, someone had set the UPS monitoring software (not seen in processes) to shutdown, on low battery signal (which I assume was the RTS or CTS lines), and not warn the user.

So you may want to check your control panel for (either UPS, or power monitoring or something like that....I do not have a XP machine in front of me at the moment), and one of the tabs will have a checkbox about monitoring (default is COM1), and see if that is set, if it is, un-set it.

Long shot, but worth a moment to check.

[Gary Peek]

....So you may want to check your control panel for (either UPS, or power monitoring or something like that....

I checked, that wasn't it. So the problem has returned! So it may still be a code issue. Oh, well.

[Michael Mattias]

>So it may still be a code issue

Indeed it may. But as of now it only The Amazing Kreskin could help you find it.

[Gösta H. Lovgren-2]

And why would the PB compiler say, "destination file write error"?

This was just broiught up a few days ago (Pierre?). If you are using JellyFish for your editor there is a quirk. It does not accept anything else on the

#Compile Exe

line. Any comments or other code just compiles the code but does not run it and yields a "destination file write error".

Just a thought.

=================================================
"We don't like their sound,
and guitar music is on the way out."
Decca Recording Co. rejecting the Beatles, 1962
=================================================

[Pierre Bellisle]

Hi Gösta,

I was under the impression that this problem was resolved
with the latest 1.66 "Jelly Fish Pro" freeware edition.

Is it the one you're using ?

[Cliff Nichols]

How dumb am I lately???

If you can get us a list of processes, or snapshots of "SysInternals Process Viewer", I am sure we can find the "Errant" process

[Gary Peek]

>So it may still be a code issue
Indeed it may. But as of now it only The Amazing Kreskin could help you find it.

Update: I started using Com2 in my application and the problem stopped. So I bought another 2 port serial board, but then the serial port associated with the modem went away. I got the modem board from my old computer and that seems to have fixed it.

We still have that issue of why the PB compiler says "destination file write error" when a piece of hardware is defective.

[Michael Mattias]

We still have that issue of why the PB compiler says "destination file write error" when a piece of hardware is defective.

I will make a guess: your actual problem does not manifest itself to the compiler until either the OPEN, WRITE or CLOSE of the target executable file fails; that , or the compiler is failing to check error codes during prior operations and the first time it does check after the 'real' error is during one of the above. (But I would think possibility #2 not likely at all).

We have had scores of threads here over the years in which it has been pointed out that "errors" do not necessarily manifest themself to an application until sometime after the REAL error. Why would the compiler - itself an application - be exempt from this quirk of the O/S?

MCM

PS: FWIW, I have sent in a NFS requesting this error message be enhanced to include text based on the WinAPI error code... eg "invalid handle", "invalid path or filename", "permission denied" etc..

[Gösta H. Lovgren-2]

Hi Gösta,

I was under the impression that this problem was resolved
with the latest 1.66 "Jelly Fish Pro" freeware edition.

It may well have been Pierre. I don't know as I don't (normally) get the error. JFF I'll try it now. (minute later). Prutting a rem after #Compile Exe causes it to compile but not run.


Trying to compile when the program already is running causes the "Destination ..." error.

Is it the one you're using ?

1.60. Don't remember the last time I UG'ed. Other than the #Compile quirk, I've seen no reason too. And because I usually use a starting template (with no other code on the Compile line). I don't have any problem with JF. Now if some new features were added ....

[Pierre Bellisle]

Yop, I did some test with JFP, problem still there....

[Gösta H. Lovgren-2]

When I compile a program that has certain "issues" I sometimes get the message, "destination file write error" if the program has been run before and there is some process still running because of the issue. Usually I can find it in the Task Manager, and sometimes using an application killer program, but how can I kill the process if I can't find it?

Just ran across this tonight when fooling around with a large string manipulation program. I was getting the same error. Here's what happened:

There was no Dialog, just a MsgBox. The program would run (compile/beep) but not show the MB. Hmm, run again & get the dfwe. Pop up Task Mgr and there was the prog running. Okay, Kill it and make a change in program, run, and ditto. Even ended up adding a Dialog but same results (no mb showed up though). Close the Dialog and get the dfwe again.

Hmmm, after a few (dozen) of these, I went and did something else to get my mind off it. Couple minutes later, I hear a beep, and sure enough there's the MB popped up.

What was happening was the string manipulation routine was taking so long (minutes) I was ending the program (via taskmgr) before the Sub was finished. ((Not expecting it to be so slow.)

So Gary, what could be happening in your program is an exceptionally long running routine (maybe an endless loop). Just a thought.

=====================================
"Nietzsche was stupid and abnormal."
Leo Tolstoy (1828-1910)
=====================================