Install python-3.5.1-embed-amd64 to c:\dev\python-3.5.1-embed-amd64
Open terminal window:
cd c:\dev\python-3.5.1-embed-amd64
python -m venv c:\dev\myenv

-> crash
Error: Command '['C:\\dev\\myenv\\Scripts\\python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 3221226505

Using debugger (VS2015) shows error:
Exception non gérée à 0x00007FFDA1D05A4E (ucrtbase.dll) dans python.exe 
And stopping debugger leave this log:
C:\dev\python-3.5.1-embed-amd64>python -m venv C:\dev\python35_x64_rtquickreport
Traceback (most recent call last):
  File "runpy.py", line 170, in _run_module_as_main
  File "runpy.py", line 85, in _run_code
  File "venv\__main__.py", line 6, in <module>
  File "venv\__init__.py", line 442, in main
  File "venv\__init__.py", line 85, in create
  File "venv\__init__.py", line 257, in _setup_pip
  File "subprocess.py", line 629, in check_output
  File "subprocess.py", line 698, in run
  File "subprocess.py", line 1055, in communicate
KeyboardInterrupt

I can't read those error messages, but I suspect this is because some of the bundled files are omitted from the embeddable package.

Using it to run venv isn't really part of the intended use cases - it's expected you'll manually install packages alongside it with your own installer. If that doesn't sound suitable for what you're trying to do, you should use the installers to install Python.

0xC0000409 (3221226505) is STATUS_STACK_BUFFER_OVERRUN due to the CRT calling __fastfail(FAST_FAIL_FATAL_APP_EXIT) in abort(). This is expected behavior in Windows 8+ 1.

Initially I couldn't reproduce this error because Python found the standard library from the system Python via the registry. After archiving (as .reg) and removing the key "HKLM\SOFTWARE\Python\PythonCore\3.5", I reproduced the problem as follows:

C:\Temp>myenv\Scripts\python.exe -Im ensurepip --upgrade --default-pip
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

Current thread 0x00000b9c (most recent call first):

venv didn't copy over python35.zip to the Scripts directory. I don't know whether there's ever a legitimate reason to look for and copy a zipped standard library, or whether venv is only supported for use with a standard Python installation.

I don't recommend doing this, but if you create the environment --without-pip, the command 'succeeds'. Then you'll have to manually copy python35.zip to Scripts and obtain activate.bat (edit this) and deactivate.bat from another install or the web. You still won't have ensurepip. If you want pip and setuptools, use get-pip.py from the web. This is all probably more trouble than you want. However, the embedding distribution is not intended to be a full Python installation that's suitable for development.

New changeset 84101e587f47 by Steve Dower in branch '3.5':
Issue bpo-26065: Excludes venv from library when generating embeddable distro.
https://hg.python.org/cpython/rev/84101e587f47

New changeset d3422b0e0cee by Steve Dower in branch 'default':
Issue bpo-26065: Excludes venv from library when generating embeddable distro.
https://hg.python.org/cpython/rev/d3422b0e0cee

I'm declaring using venv from the embeddable distro as unsupported, and it will be removed completely from the next release.

To create virtual environments, use a regular install of Python.