Skip to main content

Debugging a Batch Script, managed by the Windows Task Scheduler (Part 1)

I was contacted recently with an interesting problem that had arisen for a client where a batch script was not working as expected and silently failing in a production environment. It was being run by the Windows Task Scheduler which was reporting a '1' return code from the Task:Action history. As the script was configured to run silently there was no easy way to see what was going wrong. The Event Log did not contain anything useful and unfortunately the batch script didn't contain any logging statements. There was also a strong desire not to install any remote tooling or alter the code as it had been working previously and was currently servicing.

I thought i would share the steps taken to identify and fix the issue as it is not uncommon to be faced with a black box, which seemingly doesn't offer much at first glance, but with a little investigation, the lights can soon be turned back on.



Understanding the Stack

After some investigation it became clear that apart from 'always getting given the fun stuff' the batch script was calling python scripts, via the python runtime, which in turn called out to .Net components via Iron Python.

The basic setup of the scheduler with the task running the scripts can be seen in the screenshot below.



Looking Forward

Have put this article together in two parts. This part 1 focuses on obtaining the errors from the batch script. The second part looks at extracting the errors from the python and .Net layers.


The Solution

Something in the stack was failing but it was unclear what.

The first thing i proceeded to do was make a backup of the existing task by performing an export. This ensured we had all the properties and settings stored and provided a way back should it be required. I then used the exported properties to create a new task, essentially a copy that could be used to debug. Every care would now be required to ensure that any additions were on a read only basis in terms of affecting flow and data. After disabling the failing task it was time to get some output from the script by adding some Echo statements.
The Task Scheduler provides an 'Add Arguments' text box where i attempted to pipe the output to a text file using > c:\logs\dailyTasks.log

This gave me an initial win where i could see my newly entered echo statements from the batch file but no actual errors. 

After some digging i added 2>&1 to the end of the argument list and voila, an error appeared in my log. Unfortunately the error was still rather cryptic and not very meaningful.

I also added double pipe (>>) to 'append' rather than 'overwrite' which proved to be useful to see progress.

So the arguments to the batch file now looked as follows:
>> c:\logs\dailyTasks.log 2>&1

For those in a more traditional setup, this article will hopefully add a little help to getting the actual errors being reported from a batch script, being run and managed  by the Windows  Task Scheduler. This journey still has a way to go and for those interested in the Python and .Net integration, please read on in Part 2.



References:

http://stackoverflow.com/CaptureOutput...


Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project...


Comments

Popular posts from this blog

.Net TDD (Test Driven Development) by example - Part 1


Introduction In part 1 of this mini-series, we will develop a trivial business logic layer from scratch with a TDD approach with the goal of achieving the following:

Better code quality through Red, Green, RefactorDocumentation that grows as we develop and remains up to dateAutomatic regression test harness
This will primarily involve creating unit testsfirst, having them fail, making them pass and then refactoring the code to be of better quality and then re-running the tests. When using tools such as resharper to aid in refactoring code, having the tests in place right from the beginning really gives you peace of mind that you haven't broken anything. It also helps the thought processes while designing and developing an application or feature to be more targeted.

We will further develop the application in part 2 to add an MVC4 web client and continue the TDD story... 


Some BackgroundTest First or Test Driven development is a valuable software engineering practice. It c…

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request.

With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally.




Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below:


Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps workflow. 

Additional - Ad…

Simple Git branching strategy for release cycles

Coming up with a branching strategy that works well can be challenging when working with multiple developers and managing release cycles. A simple approach is presented here to manage release cycles, with a small to medium sized team of developers while still being able to react to production issues and fix bugs. The primary goal being to isolate work streams without impacting development progress. BackgroundGit does not enforce any particular strategy when it comes to branching which is partly what makes it such a great and flexible repository. The problems start to arise though as you move into different stages of your development process. As an example, you have a release almost complete but don’t want to impede progress on the upcoming release cycle which is where the majority of effort is required. The Basic ApproachThe focus is around producing a release while still being able to react to hotfixes or production issues without impacting on going development of features. The branches…