Curious about job objects and breakaway

[vefatica]

I see these. Why is it that way?

In WT, TCC is in a job and

Elevated:   JOB_OBJECT_LIMIT_BREAKAWAY_OK is not set

Unelevated: JOB_OBJECT_LIMIT_BREAKAWAY_OK is set

[zadjii-msft]

🤷

I don't remember having any code that deals with job objects, and surely nothing that we did for that specific to elevated scenarios.

I'd guess this is some platform artifact, and not unique to running WT elevated. I'd reckon it similarly repros in conhost, or in any other elevated host.

If it didn't in conhost, then maybe it's specific to elevated processes with package identity?

But this is definitely outside our own realm of expertise.

[vefatica]

It seems odd that some capability is lost when elevated.

If I run conhost d:\tc36\tcc.exe from the Run dialog, the shell is not in a job object.

If, instead, I run d:\wtp\openconsole.exe d:\tc36\tcc.exe (elevated or unelevated), the shell is in a job object and JOB_OBJECT_LIMIT_BREAKAWAY_OK is set. Compare to WT where JOB_OBJECT_LIMIT_BREAKAWAY_OK is not set when elevated.

I don't know about the store version; I'll check.

[vefatica]

With the store version the shell is not in a job object. Do you know why and how that's done?

[zadjii-msft]

nope. I don't know more here. Sorry!