This is a follow up of bpo-5162.

There are some occasions where you can still run into this issue. One example is if you want to spawn a new multiprocessing.Process as a child of a multiprocessing.Process:

pythonservice.exe
  - multiprocessing.Process
    - multiprocessing.Process (does not start!)

Attached is a test case. If you run this in pywin32 service debug mode, you see that the process crashes with:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Python27\lib\multiprocessing\forking.py", line 380, in main
        prepare(preparation_data)
      File "C:\Python27\lib\multiprocessing\forking.py", line 503, in prepare
        file, path_name, etc = imp.find_module(main_name, dirs)
    ImportError: No module named PythonService

In get_preparation_data is the following state:

WINSERVICE: False
WINEXE: False
_python_exe: C:\Python27\python.exe

And so you get as preparation data:

{'authkey': '...', 'sys_path': [...], 'name': 'test', 'orig_dir': '...', 'sys_argv': ['C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe'], 'main_path': 'C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe', 'log_to_stderr': False}

A workaround for me is patching get_preparation_data as follows:

    import multiprocessing.forking

    _org_get_preparation_data = multiprocessing.forking.get_preparation_data

    def _get_preparation_data(*args):
        data = _org_get_preparation_data(*args)
        main_path = data.get('main_path')
        if main_path is not None and main_path.endswith('exe'):
            data.pop('main_path')
        return data

    multiprocessing.forking.get_preparation_data = _get_preparation_data

BTW, the test case does not run on Python 3.5, but starting the service manually did work. So this is probably a Python 2 issue only.

I can reproduce the problem under Windows 7. Thank you for your example and description -- they were very helpful.

Detection that the original parent was PythonService.exe is necessary to avoid undoing the paths set appropriately for running under a service. The current code only detects the immediate parent.

Modifying get_preparation_data() in lib/multiprocessing/forking.py to perform an additional test on the inherited values from the original parent's sys.argv (available via the preparation_data key 'sys_argv') would resolve this:
if not d['sys_argv'][0].lower().endswith("pythonservice.exe"):
....

Potential complications to existing code appear very unlikely given its nature.

Patch forthcoming after running tests unless someone wants to beat me to it.

Attached is a patch for the 2.7 branch which adds the check described in the previous message.

I don't see a reasonable way to provide an accompanying test because it requires registering a win32 service (requiring administrative privileges) temporarily to attempt to provoke the issue.

Can I request that someone else run the full regression tests on this patch? I am unable to complete a standard run of tests as my Windows 7 development system is set up for building Python 3.x (newer Visual Studio) and am hesitant to fight with Visual Studio configurations.

I can confirm that this patch is working.

Maybe the test case can be modified to simulate a "pythonservice.exe" run (by patching sys.executable or something like that) so it can be run without admin privileges.

We have some business privilege management solution running which might have corrupted the installation. As no one else is reporting this issue, this is my best guest for this phenomena and I'm going to close this issue.

Wrong bug...

I opened a PR on GitHub, please review.

New changeset c47c315 by Davin Potts (Marc Schlaich) in branch '2.7':
bpo-26434: Fix multiprocessing grandchilds in a Windows service (GH-1167)
c47c315

Patch committed in 2.7 branch.

Thanks for your help, Marc.