A small lesson on VbScript - Learned the hard way

Today, we were required to write a script to gather some information from Windows client systems.  The script seemed to work fine till the "Quality Control" ghost took control.. Obviously..it was me who suggested this catastrophic idea of having "error handling" mechanism.

VbScript,  by defaul throws any error during execution as run time error.. This is a controllable behaviour though..

The two important statements are

On Error Resume Next

On Error Goto 0

The first one enables the error handling mechanism.. ie you will not be getting run time errors as earlier.. So you need to handle it manually..

And the second one disables error handling mechanisms.. any code error = run time error..

Now how to work with error handling


Err.Number will give you the error number.. and more down here

On Error Resume Next
strComputer = "fictional"
Set objWMIService = GetObject("winmgmts:\\" & strComputer)
If Err.Number <> 0 Then
    WScript.Echo "Error: " & Err.Number
    WScript.Echo "Error (Hex): " & Hex(Err.Number)
    WScript.Echo "Source: " &  Err.Source
    WScript.Echo "Description: " &  Err.Description
    Err.Clear
End If

http://www.microsoft.com/technet/scriptcenter/resources/scriptshop/shop1205.mspx#EMC

All that theory is just fine.. However, the script which has grown to around 600+ lines made us go mad.. One specific module to modify  a registry hive wont work..

And finally we found where we went wrong..

"An On Error Resume Next statement becomes inactive when another procedure is called, so you should execute an On Error Resume Next statement in each called routine if you want inline error handling within that routine."

http://msdn.microsoft.com/en-us/library/aa266173(VS.60).aspx

 

We had around 5 to 6 functions in the script. We added the "On Error Resume Next" stuff on all those and we were back on track after that.. A lesson learned in the hardway.. Long live the VbScript Error Handling.

Cheers !!

Sree

Wow... I am on Twitter now..

Yep.. Just wanted to try out what is happening out there.. Thanks to Shashi Taroor..  :-)

https://twitter.com/sreekarun

43 weird things said in job interviews

Have a good laugh guys..


My Choice:

"So, how much do they pay you for doing these interviews?" -- Jodi R.R. Smith, Mannersmith Etiquette Consulting

http://www.cnn.com/2009/LIVING/worklife/07/22/cb.you.said.what.interview/index.html

IRP Function codes and procmon

Hi guys...

Our team use Procmon a lot for troubleshooting issues.. I always get confused on different IRP messages that I see in the traces. The effort here is to map the common IRP messages and what it exactly means in a normal sense..

It will take an edit or two to take this document to an acceptable level.. so keep watching.. :-)

To Start with.. I have captured couple of points from here from MSDN



IRP_MJ_CREATE

The I/O Manager sends the IRP_MJ_CREATE request when a new file or directory is being created, or when an existing file, device, directory, or volume is being opened. Normally this IRP is sent on behalf of a user-mode application that has called a Microsoft Win32 function such as CreateFile or on behalf of a kernel-mode component that has called IoCreateFile, IoCreateFileSpecifyDeviceObjectHint, ZwCreateFile, or ZwOpenFile. If the create request is completed successfully, the application or kernel-mode component receives a handle to the file object.

IRP_MJ_CLEANUP

Receipt of the IRP_MJ_CLEANUP request indicates that the handle reference count on a file object has reached zero. (In other words, all handles to the file object have been closed.) Often it is sent when a user-mode application has called the Microsoft Win32 CloseHandle function (or when a kernel-mode driver has called ZwClose) on the last outstanding handle to a file object.

It is important to note that when all handles to a file object have been closed, this does not necessarily mean that the file object is no longer being used. System components, such as the Cache Manager and the Memory Manager, might hold outstanding references to the file object. These components can still read to or write from a file, even after an IRP_MJ_CLEANUP request is received.


IRP_MJ_CLOSE

Receipt of the IRP_MJ_CLOSE request indicates that the reference count on a file object has reached zero, usually because a file system driver or other kernel-mode component has called ObDereferenceObject on the file object. This request normally follows a cleanup request. However, this does not necessarily mean that the close request will be received immediately after the cleanup request.

IRP_MJ_DIRECTORY_CONTROL

The IRP_MJ_DIRECTORY_CONTROL request is sent by the I/O Manager and other operating system components, as well as other kernel-mode drivers. It can be sent, for example, when a user-mode application has called a Microsoft Win32 function such as ReadDirectoryChangesW or FindNextVolumeMountPoint or when a kernel-mode component has called ZwQueryDirectoryFile.


IRP_MJ_WRITE

The IRP_MJ_WRITE request is sent by the I/O Manager or by a file system driver. This request can be sent, for example, when a user-mode application has called a Microsoft Win32 function such as WriteFile or when a kernel-mode component has called ZwWriteFile.

IRP_MJ_READ

The IRP_MJ_READ request is sent by the I/O Manager or by a file system driver. This request can be sent, for example, when a user-mode application has called a Microsoft Win32 function such as ReadFile, or when a kernel-mode component has called ZwReadFile.