0

I've run into an issue in VS2013 this morning, its one of those things that I'm sure to encounter in 1-3 years (either myself or a customer), and I'm going to say "Gee, I've seen that before, but I don't know what causes it".

We build for Windows Embedded platforms and are migrating customers from VS6.0 to VS2013. Since the target hardware is still WindowsEmbedded we use the v120_xp platform toolset. I've built ?hundreds? of projects and never encountered the error I saw this morning. A customer project with lots of DLL's, I successfully rebuilt all those with v120_xp, and turned on some OPTIMIZATION for performance. Not sure this is relevant. SSE2/Qpar and optimized for FAST execution. All the DLL's build fine. The customer application builds.

But at runtime I get this warning when the ntdll.dll is loaded:

ntdll.dll 
%hs is either not designed to run on Windows or it contains an error.
 Try installing the program again using the original installation media
 or contact your system administrator or the software vendor for support. 
Error status 0x.

From this StackOverFlowLink it appears the runtime is choosing the X64 version of ntdll.dll and possibly finding the x32 bit version. I'm pretty sure its something like that, but I'm trying to understand.

1) What could trigger this behavior? I haven't seen this before with other v120_xp projects in VS2013. 2) How can I tell which ntdll.dll it is seeing? I tried dependancy walker x64 and x32 bit versions, and they seem to default different behavior.

I also played with setting compatibility mode on the exe to force Windows7 to run it in WinXP SP3 mode. That didn't work. We usually run our EXE's inside a GUI which might be forcing that...

I'm researching this today and will post my findings if I ever get to the bottom of what triggered this. Two things that are unique about this project. 1) I turned lots of Performance CPU optimizations on in the C++ module. 2) There are a lot of customer DLL modules (also built optimized). So one working theory I have is that the optimization or a DLL is tricking the runtime to thinking this is a X64 bit module.

I will be checking to see if a errent project doesn't have toolset v120_xp something like that.

Community
  • 1
  • 1
Ross Youngblood
  • 502
  • 1
  • 3
  • 16
  • Optimization is a function-by-function choice of instructions to use, and code to strip out. It doesn't affect the x86/x64 bit in the executable header. – MSalters May 19 '17 at 09:26
  • That's my assumption as well. The project contains a Large number of customer supplied modules. I'm going through a process of using an empty project and referencing each of the DLL modules one at a time to figure out what is triggering the run load time ntdll.dll issue. I was thinking that one of the optimizations might trigger some different linking behavior, but it was a remote theory. Heavy optimization is one of the unique differences between this particular project and all the others I have built that work fine. – Ross Youngblood May 19 '17 at 15:12

0 Answers0