In the company I am working in we have a management software, written by an external programmer. Let's call the software PK. PK was initially written in the 90s using C++. Since then it was regularely updated and maintained but in its core it always remained a software based on 90s technology.

We are currently in the process of migrating from Windows 7 to Windows 10 and I recieved one of the first Win 10 PCs in order to test if everything works as expected on the new OS. Everything worked but PK. PK suddenly had frequent crashes. I told the software developer that there are issues with PK under Win 10 but even after numerous updates and changes to the code we still had these crashes. The developer just couldn't figure out why it crashed although it seems to be related to the memory management of PK.

The last straw the developer saw, was to compile the software on my Win 10-PC. I compiled the source code with exactly the same version of Visual Studio 2008 and suddenly it worked. No more crashes.

So my question is:

Can it be that the same Code, compiled by the same compiler produces a different binary dependent on the version of Windows (Windows 7 and 10)?

And if so: Why?

Update: After a very long search we were able to get to the bottom of it. It was a rather complicated issue that involved differing network settings between Win 7 and 10 as well as some bugs in the software. As far as I can see the compilation on different OS had no direct effect on the bug. It worked on my PC and my PC alone when I executed the program locally but we had the same crashes on the Windows 10 PC of a colleague. Thank you all for your insights.

  • 6
    Yes and no. The compiler compiles code so it works on the target operating system, regardless of which operating system it runs on. There is a chance that the target used between his computer and yours is different, hence different code. To be more precise as to why I'd need to know the architecture, libraries, platform, and build process much more intimately than you've described. Broadly it could have been a 32/64 bit mismatch, incorrectly loaded DLL, bad registry settings, a bug in that specific version of the compiler, or even an environment variable (no joke).
    – Kain0_0
    Commented Nov 14, 2018 at 8:36
  • 1
    See write once, compile anywhere Commented Nov 14, 2018 at 10:57
  • 1
    Guys, whoever voted to close this question: this is definitely not a request for writing code or debugging a specific piece of code. It is clearly a conceptual, general question about possible interactions of the OS, a compiler and the compiler's output. Also, it is about he lifecycle of some types software, which perfectly fits to our scope.
    – Doc Brown
    Commented Nov 14, 2018 at 18:22
  • For the configuration you described, I think it is not impossible, but pretty unlikely the OS version is the root cause of the problem. I would not be astonished if you set up a fresh machine with Win7, make a fresh VS 2008 installation, and compile the program, it will behave as if it was compiled under Win10. Who knows what that dev person did with his/her machine over time? Maybe the VS installation has a different service pack level? Maybe some standard libs where tweaked? Lots of potential reasons.
    – Doc Brown
    Commented Nov 15, 2018 at 6:40

3 Answers 3


What you are describing can happen with identical binaries between operating system versions if they dynamically load different, ABI-compatible, versions of their dependent libraries. It can even happen if the libraries are byte-for-byte identical and the OS changes its memory management policies (eg. gives a little instead of a lot more memory than was requested by the userspace allocator). A crash caused by a memory fault might only affect a system whose memory allocator has a more conservative strategy than another.

Did you actually check using something like, eg. Dependencies or Process Explorer that all the libraries being loaded are the same? Have you inspected the binaries with a disassembler to see if there are differences in the generated code? Step through the code in the debugger and see where it is crashing.

  • Thank you. I'm still looking into this issue in collaboration with the software dev. Dependencies and Process Explorer is really useful. It seems that the two version are using different versions of libcurl but as far as we know both version should be linked with the same version of libcurl. I'll keep you updated
    – CKA
    Commented Nov 16, 2018 at 21:01

There may be compiler settings that are different between IS versions.

The application may invoke undefined behaviour, in which case anything can happen. I had this happening when someone introduced UB six months earlier, and it caused crashes 6 months later in totally unrelated newly introduced code.

I once had a computer with borderline faulty RAM, and it produced crashing code when one particular source file was compiled on that machine if the machine had been running for hours.

  • 2
    yeah, and visual studio is probably sneaky enough to set its default targets and compiler options depending on the operating system it is running on.
    – jwenting
    Commented Nov 14, 2018 at 9:36
  • @jwenting: it is unlikely that Visual Studio 2008 changes its default settings when run on Windows 10 (which is from 2015!). Even the lates service pack for VS 2008 was published before Win10.
    – Doc Brown
    Commented Nov 15, 2018 at 6:34

The code itself is only a small amount of what goes into the final executable; all I/O and many other things typically uses library functions, which are quite different in differing Windows version - often even between the various Windows 10 versions.

As a consequence, the code could be based on behavior in an old library code that is no longer supported, or even never should have worked but somehow did; or the code has UB which it got away with under the old library versions, but not anymore, etc.

To know for sure, you will have to analyze the code and find the reasons for the crashes - then you will know if it was always wrong and you were just lucky (90%), or if some library code is no longer compatible (10%).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.