When I start my process from Visual Studio, it is always created inside a job object. I would like to know how to turn this behaviour off. Any ideas?
I expect that it is created in a job object to be debugged. I want to place my program in a different job object.
It's not the hosting process. I'm talking about a Job Object. This is an unmanaged C++ application.
This happens when devenv.exe or VSLauncher.exe run in compatibility mode. The Program Compatibility Assistant (PCA) attaches a job object to the Visual Studio process, and every child process inherits it. Check if the job name (as reported by Process Explorer) starts with PCA. If so, PCA can be disabled as described in the link.
You can globally disable PCA using Run -> gpedit.msc -> Administrative Templates\Windows Components\Application Compatibility -> Turn off Program Compatibility Assistant -> Enable.
You can disable PCA for specific executables by adding a registry entry. For Windows 7, the appropriate registry key is HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant. In regedit, right-click that key, select New -> Multi-String Value, name it ExecutablesToExclude. Set the value to the full path of denenv.exe and VSLauncher.exe, on separate lines and without quotes. For me, these were:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VSLauncher.exe
A related issue, on Windows 7, is that executables you build in Visual Studio and run from Explorer (not Visual Studio or the command line) may run in compatibility mode, and again get job objects wrapped around them. To prevent this, your executable needs a manifest that declares compatibility with Windows 7, using the new Application Manifest Compability section. The link gives an example of a Windows 7 compatible manifest. The default manifest provided by Visual Studio 2010 does not include this Compatibility section.
I'm not aware of any ways to control this aspect of processes spawned for debugging by VS.NET. But there's a workaround, which is applicable to any situation in which VS.NET can't or doesn't start your process in the exact way you want:
Start your process (possibly using a wrapper EXE that runs as part of the post-build event), then attach to the newly started process using Tools/Attach to Process. If you break into the debugger as part of your startup code, this won't even be required (and you can also debug startup issues...).
