That pesky _debug.dbg file

PeterT · Post by **PeterT** » Fri Nov 21, 2003 10:13 am

Hello,

Can anyone please explain why I repeatedly get the message: '...the _debug.dbg file is being used by another process.' during debugging of a script.

The scenario is that I run the script from the MS editor (sometimes with debug step, and at other times run with a breakpoint), then stop the script (by clicking the stop button, or by pressing Shift-Esc - which removes the highlight from the stop button, and highlights the run button), then make some changes to the script and save it again. If I now try to rerun the script I get the above message, so I clear the message and click the stop button. At this point, the editor window will not close, and the only way to close down MS is to force an end-task operation with the Task Manager.

After the 10th time of this happening, it becomes just a tad tedious.

I see from a previous thread started in December 2002, that Armstrong Wong stated that the _debug.dbg file can become locked under abnormal circumstances. I wonder what is abnormal about what I am doing.

Thanks in advance for any info regarding this problem.
Peter

Bob Hansen · Post by **Bob Hansen** » Fri Nov 21, 2003 4:13 pm

Hi Peter...

You call it pesky, I'll call it perky! So we only have a one letter difference of opinion.

See my earlier post from many months ago:
http://www.mjtnet.com/usergroup/viewtop ... =debug+dbg

Once you understand what it is, it can be your best friend. It is not the cause of your problem, but can help bail you out. The actual issue is probably why does the script hang? I can't tell you that answer, but the _debug.dbg file is a temporary holding place for your most recent changes, BEFORE THE CRASH.

PeterT · Post by **PeterT** » Fri Nov 21, 2003 8:35 pm

Hello Bob,

Thanks for your quick reply on this issue, and your comments. I was already familiar with your earlier post, after searching the forum for any discussions involving this debug file.

Sorry, but I do not agree that the main issue is 'why does the script hang?' - as I am sure that you realise, this is the result of normal mistakes made during development of a complex program/script, and IMHO a good development environment should support this process in a predictable and reasonable way. I agree that the debug file can be a life-saver if you have forgotten to save your script before you run it, but that's a mistake that one learns not to make too often - and I am sure that a solution to this potential problem can be implemented without the obvious current disadvantage.!!

I believe that the main issue here is the question of why the debug file is still locked by the MS process (which at the same time also locks up the editor) when you stop a script running. And the only apparent solution of using the task manager to cancel MS and unlock the file is a little heavy-handed, not to say tedious. I cannot see any merits of this solution.

Maybe I am missing the obvious here, so I would be interested to hear if this failure to unlock the debug file when stopping a script has any real advantage to us as MS developers, or has any justifiable cause. I look forward to hearing fom yourself and others (particularly Marcus) regarding this issue.

Kind regards
Peter.

armsys · Post by **armsys** » Sat Nov 22, 2003 1:54 am

Hi Peter,

I'm surprised by someone quoting my comment posted a year ago. As a matter of fact, I haven't encountered the anomaly for a long while. BTW, I write my MS scripts with Multi-Edit and seldom use the debugger built into the MS editor. Nonetheless, I must emphasize both MS Editor and the debugger are invaluable tools. I'm not sure whether it has anything to do with the version.

Amongst others, there are 2 potential causes:
1. multiple instances of Macro Scheduler;
2. mysterious memory leakage of some applications which are invoked by Macro Scheduler script(s)

Killing an instance of Macro Scheduler can be readily attained by the following Macro Scheduler script:

Let>RP_WINDOWMODE=2
run>c:\Windows\Command\taskkill.exe /FI "IMAGENAME eq msched.exe" /F
Label>End
For added convenience, you may wish to add Hotkey to the script such as CTRL+ALT+K.

Hope it helps. Please do continue sharing your technical issues with us so that we can learn from each other. Happy scripting.

Bob Hansen · Post by **Bob Hansen** » Sat Nov 22, 2003 4:08 am

Good suggestion:

Let>RP_WINDOWMODE=2
run>c:\Windows\Command\taskkill.exe /FI "IMAGENAME eq msched.exe" /F
Label>End

But only works if taskkill.exe is on your system. I think that is only on WIndows NT/2K/XP, not on Windows 9x.

But the freeware program PrcView from http://www.teamcti.com/pview/prcview.htm can be used.

PrcView is a freeware process viewer utility that shows comprehensive information about running processes. This information includes such details as the creation time, version and full path for each
DLL used by a selected process, a list of all threads, memory blocks and
heaps. PrcVIew also allows you to kill and attach a debugger to a selected
process. pv is a PrcView command line utility that allows automating
common task like figuring out if particular process is running or killing a
running process on scheduler.

PrcView runs on both Windows 9x/Me and Windows NT/2000/XP platforms.

No special installation is required. Simply unzip archive to a new, empty
folder.