LabWindows 8.1 breaks in debug after a Windows library call

[LucaTesi]

Hello,

I made a project that needs to read the ethernet addresses of the net adapters installed in the pc.

The code follows:

PIP_ADAPTER_INFO pAdapterInfo;

PIP_ADAPTER_INFO pAdapter = NULL;

DWORD dwRetVal = 0;

DWORD ulOutBufLen;

UINT i;

 pAdapterInfo = (IP_ADAPTER_INFO *) malloc( sizeof(IP_ADAPTER_INFO) );
 ulOutBufLen = sizeof(IP_ADAPTER_INFO);

  // Make an initial call to GetAdaptersInfo to get
 // the necessary size into the ulOutBufLen variable

 if (GetAdaptersInfo( pAdapterInfo, &ulOutBufLen) != ERROR_SUCCESS) {
    GlobalFree (pAdapterInfo);
    pAdapterInfo = (IP_ADAPTER_INFO *) malloc (ulOutBufLen);
 }

 if ((dwRetVal = GetAdaptersInfo( pAdapterInfo, &ulOutBufLen)) == NO_ERROR) {
  return 0;
 }
 else {
    MessagePopup ("ERROR","Call to GetAdaptersInfo failed.\n");
 }

The functions invoked in this code are windows SDK functions.

In LabWindows 7 the code works correctly in debug mode and in release mode.

In LabWindows 8 all is ok in release mode, but in debug mode LabWindows breaks after first call of GetAdaptersInfo (the line GlobalFree (pAdapterInfo) is highlighted). After the break and a "Run->Continue" the program runs correctly.

I think the break is due to the failure of first call of GetAdaptersInfo; this call is needed to obtain the number of net adapters in the system. I have not any "run->break on....." checked.

Anyone knows a way to avoid this break?

[Chuck_81]

Hello Luca,

I tried to reproduce it and I do not see the behavior described.  You can try changing the Debugging Options under the Build Options menu to "no run-time checking" to see if that makes a difference. 

Is it always the first statement that it breaks on? From the looks of the code the only difference in the first call from the second is that condition is based on the return value of an assignment statement in the second call.  Try changing the first statement to do the same (i.e. if ((dwRetVal = GetAdaptersInfo( pAdapterInfo, &ulOutBufLen)) != ERROR_SUCCESS) )

Hope this helps,

Bye

Fabio

Message Edited by Fabio_81 on 02-22-2007 01:54 AM

[LucaTesi]

Hello Fabio,

    thank you for your help. I found that the behavior is due to GlobalFree (pAdapterInfo) istruction; .... from msdn(http://msdn2.microsoft.com/en-us/library/aa366579.aspx😞

[...] If an application is running under a debug version of the system, GlobalFree will issue a message that tells you that a locked object is being freed. If you are debugging the application, GlobalFree will enter a breakpoint just before freeing a locked object. This allows you to verify the intended behavior, then continue execution [...]

I didn't look before at the MSDN because in the older versions of CVI (and WinSDK) I didn't see the behavior and I thought that the problem concerned CVI.

So I changed "GlobalFree()" to a simple "free()" and now all is ok.