ReadFile Doesn't Set Event to Signaling Before Returning in 64 Bit LabVIEW

[VP14]

This may be more of a Windows OS question, but I am trying to update a driver originally developed in 32 bit LabVIEW to work on 64 bit LabVIEW. The current issue is that the WaitForSingleObject function call from the kernel32 driver always time's out when running the program in 64 bit LabView, but returns immediately (as it is supposed to do) when run on 32 bit LabVIEW.

The correct behavior of the program, and how it runs in 32 bit LabVIEW, is as follows. First, it creates an event by calling the CreateEventA function from kernel32 which is set to the signalling state and to need to be manual reset to make it leave the signaling state. Then, it uses the handle to that event to initialize an overlapped structure. The overlapped structure is then used in the ReadFile call to make it run asynchronously and return immediately. In the ReadFile call, it sets the event to not signaling for a moment, but then before it returns it sets it back to signaling. Finally, the WaitForSingleObject function is called and returns immediately with a success because the event is signaling. After that, the event is set to not signaling, but is never used again. If the program was run again, it would not make a new event, instead using the last event, and the ReadFile call would set it to the signaling state, making the WaitForSingleObject call return immediately with a success like before.

The problem, is that in 64 bit LabVIEW, the ReadFile Call does not seem to set the event back to signaling before it returns, so the WaitForSingleObject call always times out which makes the driver throw an error. The output of ReadFile is mostly the same between the two bitnesses, but strangely in the 64 bit, sometimes ReadFile returns a one, which it should not do if it is running asynchronously.

 

 

 

 

InputReportByteLength always equals 4096 when running the program in both 32 bit and 64 bit LabVIEW and CreateFile does have an input for lpFilePath, it just isn't shown.

[billko]

There was a time when LV dlls were built to run serially (for thread safety, maybe?) and it is an option in the build properties, but I forget what it is.  Perhaps it isn't related to the bitness but rather the build environment for your LV 64-bit is different than your 32-bit.

[VP14]

The problem arises before I build the driver, just running the code in 64 bit LabVIEW causes the driver to throw the error. Also, in other parts of the code that I actually did manage to get working for 64 bit LabVIEW, I had to increase the size of a couple of buffers directly because I switched from 32 bit to 64 bit LabVIEW, so I think it is safe to say that the functions being called, such as ReadFile, are switching between a 32 bit and 64 bit version when I switch between 32 bit and 64 bit LabVIEW. But just to be clear, I can compile and build the driver, it just doesn't function properly.

[VP14 · Accepted solution]

Answer

As I had said in one of the replies, previously I had to change the size of a couple buffer to make some dll calls function and this problem was no different. I had to change the event handle size to 64 bits, and for the overlapped structure I had to increase the size of its internal and internalhigh values to 64 bit as well.

[rolfk]

Of course is a Windows event a Windows HANDLE. And a Windows HANDLE is a pointer sized integer. So if you move to 64-bit you have to adjust your OVERLAPPED structure accordingly.

The whole OVERLAPPED structure is mainly a collection of pointer sized values, so it gets a great mess very quickly.

Basically in 32-bit it is a header of 4 32-bit integers followed by the 32-bit hEvent value.

In 64-bit however, it is a header of 3 64-bit integers followed by the 64-bit hEvent value.

I would not typecast the handle to a byte array that you then have to Reverse Array to revert the byte swapping performed in the Typecast but instead create something more sensible.