1
votes

I have 5 scheduled tasks that are scheduled to run every day at 9.30am. The schedule is basically a vbs script that opens an excel workbook and runs a macro. These 5 schedules can run fine if i run them seperately and 9 times out of 10 they run fine if I simulataneously run them from task scheduler. I do this by highlighting them all and then pressing run.

But sometimes when the task scheduler is doing its schedule they will fail. Sometimes all of them fail, sometimes some of them fail, but most of the time they all succeed.

Once I okay the errors(will post this next time it occurs) I can see the excel.exe in my Processes in TaskManager they are left hanging. I cannot see them in Applications because I run them in the background. Whilst here I know I can right click on the excel.exe and do a Create Dump file, but not sure what to do with this.

What I am interested here is discovering why they are failing? How do I debug it? Can I get a dump? how do i do this? I am sure the code is not perfect but the fact that they run fine seperately and most of the time fine together I am wondering is some memory resource getting used up at this time. This is what I would like to find out.

I know that i could space them out to run every minute, and this is something I might do but I would like to answer my questions above first.

Note: The vbs script in question can be found here in a previous question I asked.

EDIT1 Some useful links I have come accross following Noodles answer:
WinDBG: The very basics
question re: reading dump file

EDIT2 If i right click on check for a solution I can click on View Technical Details and that gives me: This picture ` Description Faulting Application Path: C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE

Problem signature Problem Event Name: APPCRASH Application Name: EXCEL.EXE Application Version: 14.0.7128.5000 Application Timestamp: 5398dfdc Fault Module Name: EXCEL.EXE Fault Module Version: 14.0.7128.5000 Fault Module Timestamp: 5398dfdc Exception Code: c0000005 Exception Offset: 0023e751 OS Version: 6.1.7601.2.1.0.256.4 Locale ID: 5129 Additional Information 1: 8bde Additional Information 2: 8bdedbea09a2027adb218b0e009eebf2 Additional Information 3: d4c1 Additional Information 4: d4c17b47443511f18e75ae920aa444bd

Extra information about the problem Bucket ID: 361665432 `

EDIT3 : A useful walkthough example with commands

1

1 Answers

1
votes

Crash Dumps

Load in Windbg. Then File menu - Open Crash Dump. Type !analyze (note wrong spelling)

Debugging

You can also start in a debugger.

windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.

Download and install Debugging Tools for Windows

http://msdn.microsoft.com/en-us/windows/hardware/hh852363

Install the Windows SDK but just choose the debugging tools.

Create a folder called Symbols in C:\

Start Windbg. File menu - Symbol File Path and enter

srv*C:\symbols*http://msdl.microsoft.com/download/symbols

then

windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat

You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.

Type lm to list loaded modules, x ! to list the symbols and bp symbolname to set a breakpoint

If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.

Also CoClassSyms (microsoft.com/msj/0399/hood/hood0399.aspx) can make symbols from type libraries.

You can schedule this command line instead.

Autostarting Programs in Debugger

You can also make windbg attach to any specific program when started. See gflags.exe. Only in GUI mode.

Errors

Also get the error number. TS keeps a history of runs and their errors. TS has a history tab.

.