Environment: 
 - Python 2.7.11 from python.org, x64.
 - Windows 10 or Windows 8.1
 - MSVC 2015

I compiled the most basic embedding example, taken from the Python docs:

#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_SetProgramName(argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print 'Today is',ctime(time())\n");
  Py_Finalize();
  return 0;
}

When run the call to Py_Initialize does not return and the process is terminated.

Note that I've just listed the Windows versions on which I have tested this. I have not tested on Windows 7 or Vista so do not know whether or not the issue exists there.

Probably this is related to issue 25824. When built as a console application and run from the command prompt, you should see an the error

    ImportError: No module named site

If that's the case, the problem is that even the 64-bit build is incorrectly setting the DLL version string to "2.7-32":

    0:000> da poi(python27!PyWin_DLLVersionString)
    00000000`50b878c0  "2.7-32"

So the interpreter is looking at the wrong registry key to get the default sys.path:

    python27!getpythonregpath+0x110:
    00000000`509a3d90 ff15b2d20500    call    qword ptr
                [python27!_imp_RegOpenKeyExA (00000000`50a01048)]
                ds:00000000`50a01048=
                    {ADVAPI32!RegOpenKeyExAStub (00007ffb`56f87d70)}
    0:000> da @rdx
    00000037`e4fd9940  "Software\Python\PythonCore\2.7-3"
    00000037`e4fd9960  "2\PythonPath"

As a workaround, before calling Py_Initialize, add Py_SetPythonHome("C:\\Python27"), or wherever you installed Python. Or create a symbolic link to Python's Lib directory in the directory that has your executable:

    mklink /d Lib "C:\Python27\Lib"

Or 'fix' the "SOFTWARE\Python\PythonCore\2.7" registry key by renaming it to "2.7-32". Or downgrade to 2.7.10 until 2.7.12 is released. 

That said, probably you'll use a zipped library if distributing an application, in which case this shouldn't be a problem.

Thanks Eryk, everything you described happens exactly as you describe it. Much appreciated.

As it happens, I'm not distributing Python because I want to give my users the flexibility to use whatever version they please, and with whatever third party modules they want. So I'll just advise them to avoid 2.7.11.

Why was this closed as "not a bug"? Shouldn't it have been closed as a duplicate?

I read the issue as "running an embedded Python interpreter without a reachable standard library fails", which is by design. But for 2.7 it's also apparently the design to rely on an installed copy of Python for this. (This second part is no longer recommended for 3.5+ as there are more reliable options.)

Thanks for following up Steve, and thanks for changing resolution to dupe. 

As for 3.5 and embedding the docs are much the same as 2.7 in that the example code at https://docs.python.org/3/extending/embedding.html doesn't explicitly set Python home. 

Anyway, I'm very happy with how this report has been dealt with. Thank you all.

That's true, though if you use the embeddable distribution of Python 3.5 you automatically get the equivalent behavior because of a new option (the "applocal" option in pyvenv.cfg, which is enabled in that distro by default).