Browse Prior Art Database

Software For Verifying Input/Output Processing Disclosure Number: IPCOM000177321D
Original Publication Date: 2008-Dec-08
Included in the Prior Art Database: 2008-Dec-08
Document File: 12 page(s) / 98K

Publishing Venue


Related People

Laxmi N. Rao Kakulamarri: INVENTOR [+4]


Application bugs may result from Input/Output processing operations during asynchronous I/O processing. The software disclosed herein involves the hooking of application programming interfaces related to I/O processing. This may prevent stack locations from unwinding before I/O processing completes, memory from being freed during pending I/O processing, or incorrect reusing of structures associated with I/O processing. The software verifies and validates I/O processing operations.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 27% of the total text.


There are two types of input/output (I/O) processing used in computing: (1) synchronous I/O processing, and (2) asynchronous I/O processing.    A thread performing asynchronous I/O processing sends an I/O request to the kernel.  If the request is accepted by the kernel, the thread continues processing another job until the kernel signals that the I/O processing operation is complete. The thread that was signaled interrupts its current job and processes the data from the I/O processing operation as necessary.  Consequently, asynchronous I/O processing may be more error-prone than synchronous I/O processing. 

More specifically, asynchronous I/O processing operations may be performed in three ways:

(1) overlapped I/O processing, which may use an event to signal the completion of the          I/O processing;

(2) alertable/extended I/O processing, which may use an I/O processing completion routine to signal I/O processing completion; or

(3) by using an I/O processing completion port, which may queue an I/O processing completion packet to the port to signal I/O processing completion.

Computer programs are often designed to verify applications.  For example, operating systems, such as Microsoft’s Windows® operating systems, may provide a set of application programming interfaces (APIs) for I/O processing.  If these APIs are not used correctly, certain application bugs may result, such as stack corruption.  The software disclosed herein verifies I/O processing operations by monitoring the execution of asynchronous I/O processing and performing various validations. 

The software may consist of three main components: (1) I/O processing API hooking; (2) I/O processing completion; and (3) state verification.  These three components will be discussed in more detail below.  The software is designed to catch the following application bugs:

• An application begins asynchronous I/O processing with a stack buffer (in an           OVERLAPPED structure or the data buffer), and the stack location is unwound before the I/O processing is completed.

• Memory, such as a heap block or virtual memory block, may be incorrectly made    available, or freed, while the I/O associated with this memory (OVERLAPPED or data buffer) is still pending. 

• An OVERLAPPED structure may be incorrectly reused while the I/O processing associated with it is pending.

Hooking I/O Processing APIs

The software disclosed herein may specifically verify I/O processing operations by hooking certain APIs.  For example, as shown below in Figure 1, the I/O processing software may be hosted by the vfbasics.dll or verifier.dll verifier providers.  The software may hook various I/O processing APIs.  Additionally, the software may determine whether the I/O processing is asynchron...