Windows 200 Pro - Procomm Plus crashes for no reason

[nscripta]

I maintain a couple of script that are running 24/7 as part of an alarm management system. There are three sessions running simultaneously. For no apparent reason the Procomm Plus program is stopping all the scripts and the program itself. This happens at random times throughout the week. I am monitoring the alarm manangement system remotely using PC anywhere therefore I have not seen the actual script failing. I realise the script when I do not receive my daily SMS from one of the scripts alerting me to how many alarms are active. When Procomm Plus fails the PC reverts to the desktop screen and all I do to restart the scripts is select them individually from the startup folder.

Any Ideas!!!

 

[knob]

What version of Procomm are you running? Does the program crash or just silently go away (do you get any error messages)? Are there any circumstances in the script where you have an exit or pwexit command that may be getting called unexpectedly?

http://www.aspectscripting.com

 

[nscripta]

Running version 4.8

No Error messages are displayed - maybe some sort of pop up dialog however scren not being watched at all times.

Examined event logs - no information relating to Procomm

No chance of exit or pwexit being encountered. Did think there was a chance that script were being stopped by user so I password protected one of the scripts, unfortunately procomm still 'dissapeared' so user 'tinkering' was not the issue.

 

[knob]

In that case, the only thing I can suggest is that you try downloading a couple updated DLLs you can find from my site (one is FAPI32.DLL from Symantec's site, another is an updated PWTELNET.DLC if you are using telnet) and see if those clear up your problem. Other than that, you will want to add some sort of logging mechanism to your scripts so that you can try to pinpoint where the error is occurring. For example, you can add a procedure that will write to a text file when certain operations or procedures are run, along with a time stamp. I think I have a script on my samples page from another ASPECT user that may do this.

http://www.aspectscripting.com

 

[nscripta]

knob (JS I presume!!)

I managed to be logged into the system at the time a failure occured
a dialogue box with the title 'Program Error' appeared and the text in the box stated PW5.exe has caused an error, an error log has been created....

I searched the pc for files that had been modified to identify the error log in question to no avail.

Can you suggest the next course of action?

(I have not applied the updated fapi32.dll as the scripts concerned access the serial ports directly (all information relating to this dll appear to indicate it is for fax usage - correct me if I am wrong! [No telnet in use therefore did not consider updating the respective dll])

Thanks

 

[knob]

Did the error message indicate anything more than "Program Error"? Were you able to tell what the script was doing at the time the error occurred, or did you just happen to catch the error and not the script execution?

I would go ahead and install the FAPI update and see if that helps. All serial port communications (direct connect and modem) use that module, so there's a possibility it coul help, even though the problem it resolved had to do with Procomm answering calls if memory serves me correctly.

If that doesn't seem to clear up the problem, I would try adding some of the logging I talked about in my previous message to see if you can narrow down where the problem is occurring. I thought I had something on my site that showed how to do this, but it looks like I was incorrect. Basically what you will want to do is add a procedure called LogIt or something similar that use fopen to append to a text logfile. You would then call that procedure at various places in your script, passing a string to the procedure that would be appended to the logfile so that you would know what operations were taking place. It would also be good to add the date and time as well to the string. Based on this information, you may be able to determine what your script was doing just before the crash occurred.

One other item to think about, is there any code in your script that is not called very often, such as every two or three day depending on the circumstances? If so, that would be the place to look at in my opinion.

http://www.aspectscripting.com

 

[nscripta]

I had just restarted the scripts as the pc was displaying the desktop and no scripts were running. Whilst searching for information regarding the failure the program error box was displayed and the task bar indications for the three procomm sessions 'disappeared' from the screen, examination of the processes showed no instance of Procomm was running. This failure occured about 2 minutes after restarting the scripts. There is no pattern as to when the program is stopping.
As the system is used for alarm logging there are a number of logs that are created on a regular basis (at least every 15 minutes) but there is nothing contained in the logs that indicate what has happened.
All the scripts in use have 'when $errornum' statements - no information is recorded for any scripts at the time of the failure.

 

[knob]

One thing to keep in mind is that when $ERRORMSG will only fire for non-critical error messages according to the help file, so if a critical ASPECT error has occurred, that may not get caught. What I was thinking about with respect to logging is to add in-depth statements so you can try to determine where the script is at when it crashes so that area can be focused on.

http://www.aspectscripting.com

 

[nscripta]

All the scripts are 'compiled for debug' In any instances in the past where a script has failed due to a critical error this information has always been available on the debug screen. However I agree that not all error scenarios will be getting accounted for.
I have updated the fapi32.dll and will let you know if there are further failures.

thanks

 

[nscripta]

Unfortunately, procomm plus is still stopping with the updated fapi32.dll installed. This problem seems to have occured after the machine was connected to our network. Tried asking the question regarding the failure to Symantec but they have informed me as it's a script issue they can't provide any assistance. As a test I might leave the procomm plus program running with no scripts active to see if the problem still occurs.

 

[nscripta]

The problem with procomm plus stopping whilst running the scripts is still happening. I have now identified that when the script fails an error is produced in the Dr. Watson log. The error is reported as an access violation.
Is there any further examination that could be undertaken of these logs?
To determine if the crash was happening at a particular time I wrote data to a log file whenever the procedure changed, unfortunately there is no pattern in the log file to identify where the error occurs.
There is 3 scripts used by the system, the crash only appears to happen if all three are running.

 

[knob]

If you can email me the Dr. Watson log, I can forward it to one of the former Procomm developers I know. I don't know if he'll be able to do much with it, but that's the only option I can think of. If you want to send the three scripts as well, I can look them over and see if I or he notice anything.

http://www.aspectscripting.com