64-bit strange issue, SetupDiEnumDeviceInfo

[Maxwell Chen]

Yes. :-D

Maxwell Chen

[CPallini]

And what is the error code in the 'buggy' version?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Maxwell Chen]

CPallini wrote:

And what is the error code in the 'buggy' version?

I could not get the error code. Only the 64-bit release-build got error code from this API call, not the debug-build. So I was not able to view the debug messages with DebugView. And when I added the message string for message box, the error would not come out.

Maxwell Chen

[CPallini]

You can, of course: you don't need to locally allocate a CString to show a DWORD value (you may set a global variable value, for instance). :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Maxwell Chen]

Now it is very interesting. GetLastError() = 0 when SetupDiEnumDeviceInfo fails. :laugh:

Maxwell Chen

[CPallini]

Yes, that's really interesting. Anyway, are you sure you didn't make any other API call before calling GetLastError?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Maxwell Chen]

CPallini wrote:

Anyway, are you sure you didn't make any other API call before calling GetLastError?

No. Here is the latest code for testing.

bool SetupDi::EnumDevInfo(DWORD dwIndex, SP_DEVINFO_DATA* pDeviceInfoData)
{
if(!m_hDevInfo) {
TRACE(_T("SetupDi::EnumDevInfo, m_hDevInfo is NULL. \n"));
return false;
}
if(!pDeviceInfoData) {
TRACE(_T("SetupDi::EnumDevInfo, pDeviceInfoData is NULL. \n"));
return false;
}
m_dwErrCode = 0;
memset(pDeviceInfoData, 0, sizeof(SP_DEVINFO_DATA));
pDeviceInfoData->cbSize = sizeof(SP_DEVINFO_DATA);
BOOL bRet = SetupDiEnumDeviceInfo(m_hDevInfo, dwIndex, pDeviceInfoData);
if(!bRet) {
TRACE(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
dwIndex, m_dwErrCode = GetLastError());
AfxMessageBox("SetupDiEnumDeviceInfo");

	// BEGIN: We just need this to make it work under x64. Memory alignment issue.

// CString s;
// s.Format(_T("SetupDi::EnumDevInfo, SetupDiEnumDeviceInfo(index: %d) failed (0x%08X). \n"),
// dwIndex, GetLastError());
// END: We just need this to make it work under x64. Memory alignment issue.

	//AfxMessageBox(s);
}
return (TRUE == bRet);

}

bool CPccCfgApp::FindSMBusHost()
{
SetupDi DevInfo;

// SMBus host controller should fall under the "System" devices category.
if(!DevInfo.GetClassDevs(SetupDi::eDC\_System, \_T("PCI"), true, true, true, false, false)) {
	TRACE(\_T("CFindDeviceDlg::FindDevice, GetClassDevs failed. \\n"));

// AfxMessageBox(_T("CFindDeviceDlg::FindDevice, GetClassDevs failed."));
return false;
}

DWORD dwIndex = 0;
SP\_DEVINFO\_DATA spDevInfoData;
while(1) {
	if(!DevInfo.EnumDevInfo(dwIndex, &spDevInfoData)) {
		TRACE(\_T("CFindDeviceDlg::FindDevice, EnumDevInfo failed. \\n"));
		AfxMessageBox(\_T("CFindDeviceDlg::FindDevice, EnumDevInfo failed."));
		CString s;
		s.Format(\_T("Error = 0x%08X"), DevInfo.m\_dwErrCode);
		AfxMessageBox(s);
		break;
	}

	// Hardware ID...
// ...

}

Maxwell Chen

[CPallini]

I would remove the TRACE macro and try again.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Maxwell Chen]

CPallini wrote:

I would remove the TRACE macro and try again.

Now the GetLastError() = 0x103 ( ERROR_NO_MORE_ITEMS ).

Maxwell Chen

[Maxwell Chen]

Sam Varshavchik replied me in the "C++ professionals group" forum on LinkedIn. Based on his information, I resolved this issue. The below was his comment.

Modern CPUs have no "memory alignment" issues. In the worst case scenario, the CPU will burn a few extra cycles fetching an adjacent memory word, to execute the instruction or fetch the data. No impact on the application, except for it taking a few ticks of the clock to complete.

Memory alignment issues were often an issue with older CPUs, such as the earlier versions of the Motorola 68K CPU family, where attempting to fetch a word at an odd address caused a trap. Modern CPUs just deal with this by burning more fuel, no harm done. Whatever your problem really is, a "memory alignment" issue would be on the bottom of my list of suspects.

The symptoms being described -- adding a debug statement making an apparent error go away -- often happen as a result of subtle memory corruption; such as wild pointer dereferencing, using memory after it's been freed, etc... Adding some debug statements does not really fix anything, it merely masks the bug. Many times, effects of memory corruption are very sensitive to the layout and the internal arrangement of the code in the final executable. Often, one might think that adding an innocuous debug statement magically fixes their problem, only to see things come crashing down hard, after making some other innocent change to some completely unrelated part of the same application.

There is no universal answer how to fix this, or where the problem is. Roll up your sleeves, it's old-fashioned debug time.

I often found a lot of value in a memory instrumentation and usage checker. For MS-Windows, your apparent platform, Purify is a popular tool for pin-pointing where things go astray. On Linux, I find valgrind to be indispensable, and worth every penny of its no-cost. Very often it began screaming at me about bugs in my code that I didn't even know about, yet!

Of course instrumenting code changes its runtime behavior, and might also have unpredictable results that depend on the timing of its execution -- especially with multithreaded applications. Can't win them all.

I do not have the IBM Rational Purify tool (IBM asked me to register a user account), but I downloaded and installed the 30-day trial version of Intel Parallel Inspector 2011. It reported about 30 memory errors: most of them were in the built-in source code of Visual C++ 2010, but one occurrence was in my project source code. I looked some l

[Maxwell Chen]

Hi CPallini, The issue is resolved. The detailed information is here[^].

Maxwell Chen

[CPallini]

OK, so it was a 'surviving the realease build' issue. I'm happy you finally won. :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]