I have battled this problem myself last week and consider myself somewhat of an expert now ;)
I'm 99% sure that not all dlls and static libraries were recompiled with the SP1 version. You need to put
#define _BIND_TO_CURRENT_MFC_VERSION 1
#define _BIND_TO_CURRENT_CRT_VERSION 1
into every project you're using. For every project of a real-world size, it's very easy to forget some small lib that wasn't recompiled.
There are more flags that define what versions to bind to; it's documented on http://msdn.microsoft.com/en-us/library/cc664727%28v=vs.90%29.aspx . As an alternative to the lines above, you can also put
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
which will bind to the latest version of all VC libs (CRT, MFC, ATL, OpenMP).
Then, check what the embedded manifest says. Download XM Resource Editor: http://www.wilsonc.demon.co.uk/d10resourceeditor.htm. Open every dll and exe in your solution. Look under 'XP Theme Manifest'. Check that the 'version' attribute on the right-hand side is '9.0.30729.1'. If it's '9.0.21022', some static library is pulling in the manifest for the old version.
What I found is that in many cases, both versions were included in the manifest. This means that some libraries use the sp1 version and others don't.
A great way to debug which libraries don't have the preprocessor directives set: temporarily modify your platform headers so that compilation stops when it tries to embed the old manifest. Open C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\include\crtassem.h. Search for the '21022' string. In that define, put something invalid (change 'define' to 'blehbleh' or so). This way, when you're compiling a project where the _BIND_TO_CURRENT_CRT_VERSION preprocessor flag is not set, your compilation will stop and you'll know that you need to add them or made sure that it's applied everywhere.
Also make sure to use Dependency Walker so that you know what dlls are being pulled in. It's easiest to install a fresh Windows XP copy with no updates (only SP2) on a virtual machine. This way you know for sure that there is nothing in the SxS folder that is being used instead of the side-by-side dlls that you supplied.
Sorry that I left this stagnant, but I figured out the issue I was running into. Turned out that there was corruption in the Windows XP box I was using as a test bed.
I was working between stackoverflow and another forum for the package I was writing the Add-in for. When I learned of the answer, this is what I posted, in case I ran into issue in the future.
I thought that I'd post this here, so
that I would have reference, and also
in case anyone else would need
reference to it for the future... I'm
working on another Dinerware Add-on
using WPF, and although it was running
fine on my development machine, every
time I'd go to run it on a test
machine (a machine ghosted like it was
in the field at a customer's
location), I kept getting weird
processing errors.
I did hours of searching online, only
to come up empty handed until I ran
across this article:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6e5de3d8-fc02-4504-b00f-7a2192d24a48/
which gives a link to the download of
the WIC (Windows Imaging Components),
located here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e011506-6307-445b-b950-215def45ddd8&displaylang=en
For some reason, what is/was happening
is that the Windows Imaging components
have become corrupt against what my
application is looking for. TO fix
the issue, you have to:
1) navigate to
%windir%\$NtUninstallWIC$\spuninst\
and run the spuninst.exe file in
there. That will remove the Windows
imaging components. 2) after you have
completely removed the components, you
will then re-install them using the
second link from above.
So far, I've not run into any further
issues.
What a crazy thing that
was?!?!?!?!?!?!!
Hopefully, if someone else runs into this issue, I may be able to help them out quick by >putting this out there.
As I said on that forum... hopefully this helps someone else out that runs into this issue in the future.
Best Answer
Point out that any change you'll have to introduce to these old XP machines will be similar in magnitude to the SP2 update, except that (1) you don't have the insight into the network stack that Microsoft has, (2) you don't have the experience in Windows development that Microsoft collectively has and (3) you don't have the testing resources (including beta testers) that Microsoft has. So your change will be more risky and less stable than the SP2 update.