(This is an old post from my old blog. It’s still relevant today in MDT 2013, as it was in MDT 2010)
Most of the client script in BDD/MDT are written in VBScript. VBScript is a powerful scripting language, and it is avaiable on all versions of windows that MDT supports.
I would have loved to work in a more modern language like Powershell and/or C#, however when deploying an operating system from scratch, there are very few guarantees what kind of run time environments are going to be available. The .NET framework, for example, is not available on Windows XP. So back to VBScript for me.
VBScript has the ability to skip/ignore errors if it comes across them when executing them, using the “On error resume next” command.
This can be helpful if you have a long series of non-interdependent tasks. However if you have a long set of dependent tasks, this can be problematic since the failure of any one step in the task could cause the entire thing to fail.
I would have to agree with Eric Lippert’s comments about error handling in VBScript (He was one of the architects of VBScript):
I think I’m old school in saying that error handling should be very tight. Handle errors where you expect to find them. Everything else is left to fail. I’d rather have a program end in a messy death than to blithely continue on in an unpredictable fashion. Some of my cohorts would rather do broad error handling (whole subroutines or sections of the script). They seem to assume that only the errors they expect will happen. And even if other errors do happen, it’s better to have the script finish as best it can than to do nothing at all.
Most of the code in the MDT client scripts is written with this in mind. If it’s possible for a routine to return an error, the script will handle the error cases. If the results of a routine are unexpected or bad, then we want to halt execution to be notified of the problem, rather than continue in an unexpected state.
MDT Error Handling
BDD/MDT was written with a really cool feature that allows it to pick up run time errors identified by the VBScript host program. These errors are logged to the bdd.log file for review later.
The only problem is that the built in error handling routines made available by the VBScript Host program are not as complete as if we were to run it using cscript.exe with the error written to the console.
For example, here is what an undefined variable error would look like when processed by MDT and it’s built in error handling routines:
c:\>cscript zti_test.wsf ZTI ERROR - Unhandled error returned by zti_test: Variable is undefined (500)
New for MDT 2010, is the ability to disable the “on error resume next” main error handler in all MDT client VBScript programs, with the “/DebugCapture” flag. When we run the same script with that flag, we get the following output:
c:\>cscript zti_test.wsf /debugcapture Property debugcapture is now = c:\zti_test.wsf(10, 10) Microsoft VBScript runtime error: Variable is undefined: 'UndefinedVariableFoo'
Note that when calling the script with the /debugcapture flag, the cscript.exe host program not only found the run time error as in the previous example, but it also displayed the line number where the error occurred and the name of the actual variable!?!?
Really cool stuff, and it has been invaluable for me while debugging scripts in MDT 2010.