LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

General Protection Fault when Using ReadFile from Windows SDK

Solved!
Go to solution

Hello,

 

I am attempting to use a USB device that maps to a virtual com port in my LabView CVI (8,5) application.  I get the following error:

  FATAL RUN-TIME ERROR:   "GE_Master.c", line 520, col 25, thread id 0x000004CC:   The program has caused a 'General Protection' fault at 001B:7C80188E.
 The error happens when I run the function openSerialPort (at the bottom of message) on the ReadFile line.  I am using the ReadFile from the Windows SDK (added #undef ReadFile & #undef WriteFile at the top of the file).  
 
I was wondering whether you had any ideas on what was going on and whether this is somehow to some collision with the other Readfile.  Or is there some other glaring error?
 
Thanks for any help!
 
 
 
 
int openSerialPort(void)
{
  DCB dcb;
  BOOL fSuccess;
  char tempReading[15];
  char *tr;
  LPDWORD numBytesRead = 0;
  COMMTIMEOUTS touts;
  COMMTIMEOUTS m_CommTimeouts;
  char path[10];
  BOOL fnd = FALSE; 

  char numstr[4];
  char fullpath[50];
  char firmWareID[15];
  int i;
  int cnt = 1; // want it to start checking com ports witH
  //checking COM2 first and then continue - COM1 reserved for the multimeter
  initConversionTable();
  strcpy(firmWareID, "TC Firmware");
 
 
  tr = &tempReading[0];

  while((fnd == FALSE) && (cnt <100))
    {
      cnt++;
     
      i = sprintf(numstr, "%d", cnt);
      strcpy(path, "COM");
      strcat(path, numstr);
     
      strcpy(fullpath, "\\\\.\\");
      strcat(fullpath, path);
     
      fhandle =CreateFile( fullpath,
               GENERIC_READ|GENERIC_WRITE,
               0,                 // share mode
               0,                 // security attributes
               OPEN_EXISTING,     // creation
               0,                 // attributes
               0 );             // extended attributes
     
       
     
      if (fhandle != INVALID_HANDLE_VALUE)
        {
     
          fSuccess = GetCommState(fhandle, &dcb);
          fSuccess &= GetCommTimeouts(fhandle, &touts);

          if (fSuccess)      // 1
            {
         
              // have to put in the baudRate and data for the sensor
              //http://msdn2.microsoft.com/en-us/library/aa363214(VS.85).aspx
              dcb.BaudRate = CBR_19200;     // set the baud rate
              dcb.ByteSize = 8;             // data size, xmit, and rcv
              dcb.Parity = NOPARITY;        // no parity bit
              dcb.StopBits = ONESTOPBIT;    // one stop bit
              dcb.fDtrControl = DTR_CONTROL_ENABLE;           //enabled
              dcb.fRtsControl = RTS_CONTROL_ENABLE;           //enabled
         
              // have to set the timeouts otherwise get random failures when doing ReadFiles
              touts.ReadIntervalTimeout = 50;
              touts.ReadTotalTimeoutConstant = 50;
              touts.ReadTotalTimeoutMultiplier = 10;
              touts.WriteTotalTimeoutConstant = 50;
              touts.WriteTotalTimeoutMultiplier = 10;
         
              fSuccess = SetCommState(fhandle, &dcb);       
              fSuccess &= SetCommTimeouts (fhandle, &touts);
         
              if (fSuccess)
                {
               
                  //then get back an XML line containing the temperature in C           
                      //  if (ReadFile(fhandle, tempReading, 13, numBytesRead, NULL)==0)
                    if (ReadFile(fhandle, tr, 15, numBytesRead, NULL)==0)                <----------------------------   Error is here
                      //if (ReadFile(fhandle, tempReading, 13)==0) //using the Labview Readfile
                        {
 ....

}

 

 

Windows Readfile: http://msdn.microsoft.com/en-us/library/aa365467(VS.85).aspx

Message 1 of 5
(4,822 Views)

sure, your call to ReadFile is wrong.

 

parameter 4 is of type LPDWORD, that means a pointer to a DWORD: ReadFile() will store the number of bytes read there. (in other words: this is an "out" parameter).

you passed only the DWORD... the line should be:

 

if (ReadFile(fhandle, tr, 15, &numBytesRead, NULL)==0)

 

as a side note, here is some of the Windows SDK conventions for type prefixes:

- "LP" is a "long pointer", where "long" means "far" and is historical.

- "C" is constant. 

- "W" is wide, for string it means unicode,

- "T" for string types means either ANSI or UNICODE depending on the compilation flags

now you should be able to determine what "LPCTSTR" is...

 

Message Edited by dummy_decoy on 10-23-2008 10:21 AM
Message 2 of 5
(4,820 Views)

Thank you for your explanation.  I believe your correct - documentation says a pointer is necessary.  

 

The only problem when I try to make it a pointer is that, I get a compiler error:

  520, 63   Type error in argument 4 to `ReadFile'; found 'pointer to LPDWORD' expected 'LPDWORD'.

 

The compiler is not looking for a pointer.  I have also tried the following:

LPDWORD *numBytesRead = 0; 

 

 if (ReadFile(fhandle, tr, 15, numBytesRead, NULL)==0)            .....

 

and I still get the same error.  How do which Windows.h file it is getting its definition from?

 

0 Kudos
Message 3 of 5
(4,817 Views)
Solution
Accepted by topic author anish.thomas@degreec.com
Declare numBytesRead as a DWORD rather than an LPDWORD, then pass &numBytesRead into the function. This is a common ambiguity with parameter types that requires you be aware of how that parameter is going to be used. It's an output parameter, so you have to allocate its storage on the stack by declaring a variable of the proper type (DWORD), and then pass the address of that storage (&numBytesRead).
Message Edited by Mert A. on 10-23-2008 11:13 AM
Message 4 of 5
(4,813 Views)

Thank you to both dummy_decoy & Mert A. You both clearly explained the problem - I just have to read what you say and not rush.

 

I now have my project compiling & running.  I'm able to talk with my USB device over the vitual com port.  I'm getting some other errors but I should be able to figure those out.  

 

 Thanks again for your quick & helpful response!

Smiley Very Happy 

0 Kudos
Message 5 of 5
(4,808 Views)