I am reversing an application that uses the serial interface (COM1 port) and am using API Monitor to trace through the API calls.

I found a reference to CreateFileA("\\.\Commsb96", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL). I believe this is opening the serial port.

Shortly afterwards, the code runs DeviceIoControl, with the dwIoControlCode (second parameter) set to 0x0022002b.

API Monitor identified that as IOCTL_INTERNAL_USB_RECORD_FAILURE. Given that this is not a USB device, I suspect this is a mislabeling. If so, how do I identify what 0x0022002b is?

And if not, what the heck is IOCTL_INTERNAL_USB_RECORD_FAILURE. The calling DLL is VcomSB96.dll.

Thank you!

  • 1
    These are probably not COM devices. COM device descriptor names are in the format of "\\.\COM1". where the digit 1 represents the COM device id. Is it possible that the application loads it's own driver?
    – NirIzr
    Oct 22, 2016 at 3:24
  • According to Microsoft, 0x0022002b is also IOCTL_BTHHFP_STREAM_OPEN which hints at a bluetooth device. Are you sure that's a real com port, or rather a bluetooth adapter that emulates RS232 over bluetooth? I found this by googling for 0x0022002b; in many cases googling for this kind of specific magic number yields something useful. Oct 22, 2016 at 4:03

2 Answers 2


As Nirlzr said, this was not a COM1 device. It was a virtual device, which functioned as an intermediary to the actual COM1 interface. I debugged the .sys file, which was just using IOCTL_INTERNAL_USB_RECORD_FAILURE, but was merely using that IOCTL command.


The meaning of any one Device I/O Control code is subject to some convention. Microsoft defines the code in bit fields, the most notable of which is the high word as a device type. Microsoft defines many I/O control codes for many types of device. If a driver is executing to handle that type of device, it should expect to receive those corresponding I/O control codes and to interpret them as Microsoft defines. These I/O control codes are in this sense well-defined such that if you or a diagnostics tool see one, identifying it by a known symbolic value is sound.

However, drivers can create device objects that have nothing to do with hardware. Such devices won't be the target for any device I/O control to help with managing any type of device that the system knows or cares about, and so the driver can make up whatever I/O control codes it wants. This is a long established mechanism by which drivers communicate with a co-operating application.

Conventionally, I/O control codes that are invented for this purpose tend to have 0x0022, i.e., FILE_DEVICE_UNKNOWN, as the device type. The practical consequence for you in your reverse engineering is that the same device I/O control code that has 0x0022 as the high word can mean completely unrelated things to different devices, even if implemented in the same driver.

Now, Microsoft does muddy the water a little by using FILE_DEVICE_UNKNOWN for I/O control codes that can be sent to drivers for physical devices. But unless you or your diagnostics tool know that you're looking at a driver that's in place to receive those I/O control codes, any symbol that the tool resolves a 0x0022XXXX number to is very likely a fantasy that you do better to ignore.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.