I have used the option "This build is parameterized" and add a "String
Parameter" with Name=BUILD_ID and Default Value=dontKillMe.
And now it works.
BTW having a checkbox which says "don't kill child processes" could be more easy.

• • • Issue 3125 has been marked as a duplicate of this issue. ***

+1 on the checkbox/option idea; using parameterized or modifying the scripts as suggested isn't exactly
intuitive

I think this would best be handled by a plugin that adds a UI element for each
project, or each build step even, that disables the process tree killer. I don't
think this applies to enough users to add it to core.

The BUILD_ID environment variable has been working well for most users.

Details on this workaround work, please?

Does it prevent intentionally killing/aborting a build?

Can a build step in the job just set a BUILD_ID envvar?
Is the specific value "dontKillMe" required, or will any value work?

Adding a parameter to every one of our many jobs (and new ones) would be a hassle, even if users could accept a default value.
Can the BUILD_ID envvar be set in the overall Jenkins configuration to affect all Jenkins jobs?
Can the BUILD_ID envvar be set at the OS level to affect all Jenkins jobs?

We have had to restrict many of our jobs to run on nodes with only a single executor to ensure that the situation doesn't arise. A real fix would be most helpful.

@mdonohue: I think it does apply to enough users.

Lots of us are using concurrent gmake builds without a problem on linux machines, and lots of us want to do just the same for msvc builds under windows.

It would be definitely nice to have a checkbox for a "Windows Batch Command" build step or something like this, because a typical use case is not to kill mspdbsrv.exe for simultaneous visual studio builds.

As it seems vaguely appropriate, I shall repeat here for interested parties what I've just commented on issue #9104 :

Visual Studio is so ubiquitous that I personally think this could warrant a special case built into Jenkins, but anyway this is what we have just started doing (before calling devenv but after the MSC setup.bat has been called) to work around this (for all Windows builds):

:: PITA to keep MSPDBSRV alive
set ORIG_BUILD_ID=%BUILD_ID%
set BUILD_ID=DoNotKillMe
start mspdbsrv -start -spawn
set BUILD_ID=%ORIG_BUILD_ID%
set ORIG_BUILD_ID=

It seems, from reading around, that the Jenkins process “tree” killer rummages through the whole process tree looking for processes with the environment variable BUILD_ID set to what Jenkins originally set it to, and killing any it finds. The above temporarily changes that to something else (anything, you could even just blank it), launches mspdbsrv manually (so it has the altered env. var.) and then puts it back (to restore the usual no-resource-leak fix).

When you run mspdbsrv, it seems to immediately exit if there's already an appropriate version running, so it doesn't matter having multiple jobs trying to kick it off.