C / C++ / MFC

	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."));
			break;
		}

		// Hardware ID.

CPallini wrote:

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

CPallini wrote:

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

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...
	// ...
}

CPallini wrote:

I would remove the TRACE macro and try again.

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. 

bool SetupDi::GetClassDevs(SetupDi::DeviceClass DevClass, PCTSTR sEnumerator,
		bool bAllClasses, bool bPresent, bool bProfile,
		bool bDefault, bool bInterface)
{
	const GUID* pGuid = NULL;
	switch(DevClass)
	{
	case eDC_System:
		pGuid = &GUID_DEVCLASS_SYSTEM;
		break;
	default:
		break;
	}

	DWORD dwFilter = 0;  // This line caused x64 release-build to fail.
	if(bAllClasses) {
		dwFilter |= DIGCF_ALLCLASSES;
	}
	if(bPresent) {
		dwFilter |= DIGCF_PRESENT;
	}
	if(bProfile) {
		dwFilter |= DIGCF_PROFILE;
	}
	if(bInterface) {
		dwFilter |= DIGCF_DEVICEINTERFACE;
	}
	if(bDefault && bInterface) {
		dwFilter |= DIGCF_DEFAULT;
	}

	m_hDevInfo = SetupDiGetClassDevs(pGuid, sEnumerator, NULL, dwFilter);
	if(!m_hDevInfo) {
		TRACE(_T("SetupDi::GetClassDevs, SetupDiGetClassDevs failed (0x%08X). \n"), GetLastError());
	}
	return (NULL != m_hDevInfo);
}