Question

I’m working on a program in C# which communicates with a piece of hardware over the serial port (said serial port communication being handled by a C++ library). It is meant to replace an earlier piece of software which has become unmaintainable. Currently, it is not working at all how I desire it to. On my work laptop, using the old program works fine. Using the new program with the old DLL works fine. Using the new program with the DLL compiled in debug mode fails (previously, I was able to compile the DLL in release mode and get it to work but since then, settings were changed in the project which cause it to fail even in release mode). Specifically, I’ve traced it with a serial port monitor and it’s when I’m sending the SOM (Start of Message). I send “IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_IMMEDIATE_CHAR: Transmit immediate character),DOWN,TRUE,0x0,3A ,:” and that seems to succeed. I then do a “IRP_MJ_READ,DOWN,FALSE,0x0,,” which is answered with “IRP_MJ_READ,UP,FALSE,0x102,,”, the error. This exact same sequence of events passes when working with the non-debug DLL.

I have been unable to find a reference to 0x102 as a return code and not everyone experiences the same issue. My compatriot on the other side of the Pacific occasionally sees this error, but only when running through a virtual machine (He’s running on Windows 7 but we were recently required to develop for XP running on a VM.

Anyone have any ideas what could be the situation here?

Update

Well, apparently moving to .Net is a no-go according to my boss. Legacy reasons. I’ve got the timeouts up to 10 seconds and it still times out with the DLL compiled in Debug mode. I have found out that when running on the Release mode of the software, it looks like the call is routed through rpcld.exe, which is associated with Absolute Software’s LoJack anti-theft system. When compiled in Debug mode, no such call is made. Makes me wonder if the serial ports are getting locked down unless one routes through there. I’ve left a message with one of their customer service representatives just in case. That could explain why it worked on my counterpart’s computer until he moved into the virtual machine.

Answer 1

MS says that 0x102 is an NTSTATUS meaning

The given Timeout interval expired.

http://www.stallion.com.au/html/userdoc/easyadmw/easyadmw_2.html says something similar

Last Status This is the NT_STATUS code of the last Read IRP
(IRP_MJ_READ) completed by the driver. The actual code can be decoded
from the NT DDK file ‘ntstatus.h’, however any value except for
STATUS_SUCCESS (0x0) or STATUS_TIMEOUT (0x102) is usually considered
an error.

Perhaps the new DLL needs to be modified to use a higher Timeout when communicating with this device…

OR you just discard the DLL and use the SerialPort class…

several useful links:

• http://msdn.microsoft.com/en-us/library/aa363190%28v=vs.85%29.aspx
• http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.aspx
• http://www.dreamincode.net/forums/topic/35775-serial-port-communication-in-c%23/
• http://www.codeproject.com/KB/system/Serialport_COM.aspx
• http://msdn.microsoft.com/en-us/library/ff549327%28v=vs.85%29.aspx
• http://msdn.microsoft.com/en-us/library/ff550671%28v=vs.85%29.aspx
• http://msdn.microsoft.com/en-us/library/cc704588%28v=PROT.10%29.aspx

EDIT:
According to the comment from OP the read timeout is set 1000 ms (timeout = Interval * multiplier + constant), since multiplier is 0 the constant of 1000 (ms) is the used timeout for read operations.

EDIT 2 – AFTER the UPDATE of the OP:

You didn’t provide the information what sort of device this is in the original Post – such devices usually implement some sort of “anti-debugging” technique… which is probably exactly what you are seeing… such measures are implemented due to the usage of such devices: with a debugger one could compromise the effeciency of the device… so to be able to make such a device you need to implement some measures to make it at least harder on any attacker… no such scheme is 100% secure…