adeyblue

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.

Your WM_HSCROLL switch is faulty:

http://msdn.microsoft.com/en-us/library/bb760149.aspx#tkb_notifications
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.

LPD3DXEFFECT CreateEffectFromFile(LPDIRECT3DDEVICE9 d3ddev,
           				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.

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.

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.