When I get a request for assistance with a VBScript, I often reply with the sentence: 'Breakdown your script into its simplest components, get each command working in isolation,
only then bolt the sections back together'.
In my own scripts you may see traces of troubleshooting sections in the form of extra WSCript.echo messages. Sometimes I forget to remove them after testing the script, on other occasions I deliberately
leave the WSCript.echo statement, just to alert you that VBScript has performed an action.
The reason this strategy works is because you simultaneously build on success while narrowing down the search
area for the fault.
Start solving VBScript errors by playing the numbers game.
Rule 1) Trace the line numbers of the error.
Rule 2) Check the hex numbers (Here is my section on error code numbers) Rule 3) Get the phone number of a friend, or even the phone number of Microsoft Support.
While you play the numbers
game, pretend you are Sherlock Holmes searching for clues.
Look for patterns. Take these two error messages 800708CA and 800A01F4; with just a glance at 800708CA I can tell this is an operating system problem, the clue is that '7' in position 4. Notice how in the second hex number, 800708CA, we have an 'A' in position
4, thus indicating a syntax error.
Further research indicates 800708CA means network connection does not exist, whereas 0800A01F4 means variable undefined. Incidentally, the underlying
problem was trying to remove a network drive that did not exist.
Get a good script editor. When you are troubleshooting, you need every advantage that you can get, thus a script editor will help by displaying the line numbers. The advantage is that when get a
WSH error message you won't have to count down to line 81 or where ever the message directs you.
The better script editors also color code the commands, as a result you can often see a sudden
change to red letters where you make a typo. As a bonus good script editors give you a context sensitive library of commands, which extends your scripting vocabulary. These days,
my choice of script editor is OnScript.
It is amazing how often a manual walk-though of the task sheds extra light on
a scripting problem. In particular, watch out for steps that are missing in the script. For example, pressing the OK button in a dialog box requires the VBScript command: obj.SetInfo. Following this theme, as you step through the task
manually,
observe how the
default radio buttons are set.
Another advantage of a walk-through is that may reveal that what you want to achieve cannot be done with a VBScript. Trust me, I have a whole folder full of readers' plans for mission
impossible. Many plans sound plausible until you try a walk-through. For example, I had a request to add a photograph to each user's property sheet. Could I kindly help with a
script. It seemed a nice idea until a walk-through in Active Directory Users and Computers exposed that there is no way of adding a user's photograph. It also struck me that even if the script could
magically achieve the mission, then how would you see the photo?
4a)
Suppose that your mission is to map a network drive, but the script just won't work. Instead of going around in circles, try mapping a printer. If that also fails, look for a common cause, for
instance, the fault maybe because you are created an environmental object instead of a
network object. By trying a parallel approach you can isolate the error.
4b) Here is another example, you are trying write to a file; but it fails, why not try to read from a file instead? This will prompt you to re-examine the Const statement and also to check that
folder\file referenced in the script, is where you think it is.
4c) Cannot run Excel? Try to run Notepad instead, if that works it could mean that Excel is not installed.
4d) Seek similar examples
on the internet. Leave a request in your favourite forum.
My hidden message with this approach is when the parallel command
works, you are at the start of a winning roll of the VBScript dice. What I find is that when I get even a small success, then my confidence grows and what was a difficult problem, suddenly
becomes a cinch. Don't underestimate the power of positive thinking.
Perhaps what you need to solve the problem is sharper focus,
or greater attention to detail. In this case, break out of that terrible loop where you go around in circles. Print out your script, but take it to another room where you read each line carefully. Don't ask me why, but it works for me. A psychologist may say that I associate the
dinning room with concentrating on fine detail.
I repeat that when it comes to troubleshooting getting into a positive frame of mind is as important as technical
know-how. Thinking positively opens up the mind to alternative avenues,
for example, leave a question in a forum, or email-a-friend. To fix a script that's not working, you need to develop the 'can do', or 'I can walk on water mentality'. Let me play devils advocate for a
minute, if you are in a bad mood, then common sense dictates that this negative attitude will sap your problem solving abilities.
Blame someone. I don't like this idea at all. However, my friend 'Mad' Mick swears that sticking pins in cabbage patch doll labelled Bill Gates, fires
up his brain and solves the problem. Physical out bursts do not work for me, but if punching the door, or kicking the wall makes you feel better and gets you into problem solving state, then who
am I to judge. Incidentally, this indicates I am willing to publish tips even if they don't work for me.
'Over-think' can be a bit like amateur bird watchers. When out 'twitching' they always claim to have seen a rare exotic finch, when what they are really looking at is a Great Tit. In the case
of amateur script writers they claim it's a rare VBScript error, when actually they have left a bracket unclosed. My message is start by looking for the simplest, most likely cause of the errors, checking for
typos would be a good place to begin. Naturally a good script editor helps to identify such errors either by color coding or through pin-pointing the line with the fault.
It never ceases to amaze me how many people solve their own problem simply by writing down what has gone wrong and what they want their script to achieve. How do I know this? Because lots of people
write to me for help with their scripts. When I reply, I would estimate that 30% of people say in the meanwhile (a few hours) they have solved their problem. I am able to assist a further 30% by
giving them a fresh insight, or by nudging them in the right direction. All that I have done is act as a sounding board and magically they see how to correct the error.
In conclusion, if only more people would simply write down the problem and reflect on the desired result, then their brain will conjure a solution. For some people and certain types of problem, drawing
diagrams helps clarify what's happening and thus points to the way out of the scripting maze. Drawing a 'Pipe' between the user object and Active Directory would be a case in point.
Try
a different solution, download SolarWinds ipMonitor
Here is my thinking,
ipMonitor will give you valuable data about your network and servers.
This extra information just may unlock the solution to your error code.
One more thing, sometimes when troubleshooting you go around in circles;
therefore if you try a different, but related approach, you may just crack the
problem.
Free Download
of SolarWinds ipMonitor
Their topics and material are ideal for getting you started with VBScript. The
videos are easy to follow and you can control the pace. Try their free demo material and then see if you want to buy the full package.
See more about VB Script Training CD.