Curious about job objects and breakaway

[Vincent Fatica (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

[Mike Griese (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.

[Vincent Fatica (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.

[Vincent Fatica (vefatica)]

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

[Mike Griese (zadjii-msft)]

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