Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Dec 2008
Offline Last Active Apr 11 2016 03:01 PM

#4892546 Wow64cpu module

Posted by on 10 December 2011 - 10:29 AM

On 64-bit computers, Process Explorer is a 64-bit program so it exists outside the 'emulator' and can see into it.

To get the full user-mode call stack of a WoW64 thread, call GetThreadContext and StackWalk64(IMAGE_FILE_MACHINE_X64, ...) (for the 64-bit code), then call Wow64GetContextThread and StackWalk64(IMAGE_FILE_MACHINE_I386, ...) (for the 32-bit code)

To get the kernel side stacks that Process Explorer also displays requires a driver and peeking into documented-but-not-officially-so structures.

#4840834 Overlapped File IO Interfering with Winsock

Posted by on 26 July 2011 - 04:11 PM

All I'm doing in my file io code is calling ReadFileEx with the overlapped struct set, and no completion routine.

That's the problem. Despite what the docs say, the completion routine isn't optional. If you set it to NULL, Windows will try and call it which will go bang. My comment about this has been at the bottom of the functions' MSDN page for about two years now. Guess they don't want to, or are unwilling to fix either the docs or the code.

#4835061 Trackbar control in Visual C++

Posted by on 13 July 2011 - 06:30 PM

Your WM_HSCROLL switch is faulty:

The low-order word of the wParam parameter of WM_HSCROLL or WM_VSCROLL contains the notification code. For the TB_THUMBPOSITION and TB_THUMBTRACK notification codes, the high-order word of the wParam parameter specifies the position of the slider.

You want to be switching on LOWORD(wParam) instead.

#4828529 Strange SIGSEGV fault

Posted by on 27 June 2011 - 09:51 PM

           				LPCTSTR shaderFile, <<---- This here
           				LPD3DXEFFECT effect,
           				LPD3DXBUFFER errorLog,
           				D3DXHANDLE* technique)

Don't put types that can and do change based upon compiler flags in dll interfaces.

It's entirely likely that the dll of the non-working version is compiled with UNICODE defined which would make that parameter a "LPCWSTR shaderFile" while the app (which doesn't have UNICODE defined) sees it as "LPCSTR shaderFile". If this is the case then the string being passed to D3DXCreateEffectFromFile is borked and your lack of error checking lets the function blow up dereferencing a NULL/garbage tempEffect variable.

This is probably what ApochPiq was getting at but it's something you need to be aware of even if this isn't your immediate problem.

#4816913 COM, 64 and 32 bit dll at the same time?

Posted by on 28 May 2011 - 03:04 PM

If I built a 64 bit version of the dll, would it be possible to have it registered while the 32 bit version is also registered, and automatically have the correct one loaded, depending on whether the calling process is 64 or 32 bit?

Should be perfectly fine. There are two versions of HKEY_CLASSES_ROOT on 64 bit Windows, the registrations wouldn't overwrite each other. The 32-bit version is accessible under the HKCR\Wow6432Node\ key in regedit.

Then the calling app does CoCreateInstance or the .Net equivalent and the loading will hopefully be transparent.

#4785076 Win32 Common Controls !

Posted by on 12 March 2011 - 08:36 PM

Sounds like your code is linked to the 'classic' v5 version of comctl32.dll. That version doesn't handle ICC_STANDARD_CLASSES since in classic style apps those components are handled by user32.dll (they're the ones that look like they're from Win95). The updated or XP style controls are handled by comctl32 but a manifest is required to pull in the proper dll version. There's an example of a v6 manifest here if you Page Down twice, along with more than anybody needs to know about the process.