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

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

CPallini wrote:

I would remove the TRACE macro and try again.

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

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

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

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

Yes. :-D

Maxwell Chen

Because I am using it this way... :-D

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.

Maxwell Chen

I have been working on SetupDi API functions with VC++ 2010 during these couple days. It works well with 32-bit and 64-bit debug-build, but not the 64-bit release-build. I added some AfxMessageBox'es to narrow down where the problem was. It failed in the API SetupDiEnumDeviceInfo. But when I formatted a CString in the error handling block after the SetupDiEnumDeviceInfo call, the problem was gone. It looks like some memory alignment issue (well, I guess). Anyone knows the correct way to resolve this kind of issue? (1) The below code fails.

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;
}
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, GetLastError());
}
return (TRUE == bRet);
}

(2) The below code works well.

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;
}
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, GetLastError());

	// 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);

}

Maxwell Chen

How about LoadImage[^]?

Maxwell Chen

Cool_Dev wrote:

That thread says that the error code 5 can be ERROR_CANTWRITE also. Have a look into it. you can ensure it by checking the value got in in PHKEY argument. Also try using KEY_ALL_ACCESS Or KEY_WOW64_64KEY in RegOpenKeyEx.

Hi Cool_Dev, 1) The name KEY_WOW64_64KEY is not defined in VC++ 6. So I did not add it since the compiler said "undeclared identifier". 2) RegOpenKeyEx returns value 0 in the PHKEY argument. 3) I have been using KEY_ALL_ACCESS all the time. 4) During run-time seen on the debugger, ERROR_ACCESS_DENIED is 0x0005 and ERROR_CANTWRITE is 0x03F5. Please refer to the screenshot[^] on VC++2005 remote debugger.

Maxwell Chen

Richard Andrew x64 wrote:

Open Task Manager, find the process that represents your service and check what user account it is running under.

Hi Richard, My service is running under the name SYSTEM. (The logon session user account is "user".)

Maxwell Chen

Hi Shilpi,

Shilpi Boosar wrote:

Are you sure that your application is launched with admin priviledge ??

I think so. I right-click on the Command Prompt shortcut, and choose "Run as Admin", to open a DOS-box. And then I type the command: MyService.exe -r to setup and start the service.

Maxwell Chen

Hi Cool_Dev, I roughly had a glance on the discussion thread just now. In the thread, they came out with the solution using manifest file, right? Answering to your question: Yes, I am on Windows 7 32-bit platform. My code is to be compiled with VC++6 and WDK 6000. So manifest files might not be the solution to this issue ... I guess.

Maxwell Chen

I am trying to access this key in my code (which is a Windows Service and is launched with admin privilege): HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture and I keep getting the error code 5 (ERROR_ACCESS_DENIED). I followed this solution[^] to adjust the token privilege. This step succeeded, but then RegOpenKeyEx still returned ERROR_ACCESS_DENIED. What else should I do to access this key? Thanks in advance.

Maxwell Chen

The root cause is in the ico file. Do not use PNG (do not compress) for the 256 x 256 and 128 x 128 frames. Use BMP (uncompressed) instead. And the issue is resolved.

Maxwell Chen

We have the extra large icon view (256 x 256) since Windows Vista. Now I have a control panel applet running under Win7 and Vista. I have added the icon resources with images of size 256 x 256 into the CPL. But the shortcut (on the Desktop) to this CPL applet does not display the icon correctly. It is said that assigning the value CPL_DYNAMIC_RES for the idIcon member of CPLINFO structure in the CPL_INQUIRE message handler triggers Windows to send a CPL_NEWINQUIRE message. And then we assign the hIcon member of NEWCPLINFO in the CPL_NEWINQUIRE message handler for the icon information. But no matter AfxGetApp()->LoadIcon or ::LoadImage (even with the LR_DEFAULTSIZE flag) fails to make the icon image of the shortcut on the Desktop display the correct sized image. Does anyone know the correct way to handle the CPL_INQUIRE and CPL_NEWINQUIRE to make it display 256 x 256 image for the shortcut on the Desktop? Thanks in advance.

Maxwell Chen

fat_boy wrote:

Just saw this vid on the same page!

:wtf:

Maxwell Chen

Dog with schizophrenia. :laugh: Watch on YouTube[^]

Maxwell Chen

Driving from Taiwan to the Santa Clara U.S., Google Maps even tells me to swim across the Pacific Ocean. Screenshot[^]

Maxwell Chen