I find that the JobLab sample always exits early with the message "Process already in a job". I don't understand why this is but when the "IsProcessInJob" call is removed the sample runs just fine.

Question

I find that the JobLab sample always exits early with the message "Process already in a job". I don't understand why this is but when the "IsProcessInJob" call is removed the sample runs just fine.

Opened this issue 6 years ago · 6 comments

Answer 1 · 2020-03-03T15:34:00.000Z

I find that the JobLab sample always exits early with the message "Process already in a job". I don't understand why this is but when the "IsProcessInJob" call is removed the sample runs just fine

Answer 2 · 2020-03-03T21:14:26.000Z

Hi MRahilly.

I noticed you closed this issue; did you want me to investigate this?

Answer 3 · 2020-03-04T09:41:43.000Z

I would be grateful of you could let me know if you get the same result as I do with the JobLab sample, that is, early termination when the IsProcessInJob call returns TRUE. From: Vasilios Magriplis [mailto:notifications@github.com] Sent: 03 March 2020 21:14 To: yottaawesome/windows-via-c-cpp <windows-via-c-cpp@noreply.github.com> Cc: Marcus Rahilly <mrahilly@AIT.IE>; State change <state_change@noreply.github.com> Subject: Re: [yottaawesome/windows-via-c-cpp] I find that the JobLab sample always exits early with the message "Process already in a job". I don't understand why this is but when the "IsProcessInJob" call is removed the sample runs just fine. (#1) Hi MRahilly. I noticed you closed this issue; did you want me to investigate this? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#1?email_source=notifications&email_token=AGJXXXCUAYCY44X42VJDLUDRFVXLFA5CNFSM4LAM6NI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENVFSIA#issuecomment-594172192>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGJXXXERFVH4CJ2Y2JYSVPLRFVXLFANCNFSM4LAM6NIQ>. Tá an t-eolas atá le fáil sa ríomhphost seo faoi iontaoibh agus tá sé ceaptha le haghaidh aird an fhaighteora bheartaithe/na bhfaighteoirí beartaithe amháin. Más rud é go bhfuair tú an ríomhphost seo go hearráideach, ná húsáid agus ná tarchuir é ar mhaithe le haon chuspóir, le do thoil; ina áit sin cuir ar an eolas muid láithreach agus scrios gach cóip den ríomhphost seo ó do chóra(i)s ríomhaireachta. Ach amháin sa chás gur comhaontaíodh a leithéid go sonrach ag ár n-ionadaí údaraithe, is le húdar an ríomhphoist amháin na tuairimí a chuirtear in iúl ann, agus ní léiríonn siad tuairim ná ní chuireann siad ceangal ar aon chaoi eile ar Institiúid Teicneolaíochta Bhaile Átha Luain. Déan teagmháil le administrator@ait.ie nó cuir glao ar 090 6468000. The information contained in this email is confidential and is designated solely for the attention of the intended recipient(s). If you have received this email in error, please do not use or transmit it for any purpose but rather notify us immediately and delete all copies of this email from your computer system(s). Unless otherwise specifically agreed by our authorised representative, the views expressed in this email are those of the author only and shall not represent the view of or otherwise bind Athlone Institute of Technology. Contact administrator@ait.ie or telephone 090 6468000.

Answer 4 · 2020-03-04T21:15:59.000Z

OK, no worries. I'll try to look at this today or tomorrow evening after work.

Answer 5 · 2020-03-05T06:02:24.000Z

I'm just going to reopen this issue to keep track of it.

Answer 6 · 2020-03-05T07:27:26.000Z

I get the same behaviour with the process starting in a job object, and this happens in both 32 and 64 bit builds, and when debugging or running the application manually. I can query some amount of the job object the process resides in using QueryInformationJobObject(): https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-queryinformationjobobject. You can also view the job ID of a process in Task Manager > Details and selecting Job object ID.

However, disabling the check at the beginning allows the sample to continue, and it (mostly) appears to be working fine. This is OK if you're running on Windows 8 or later, as the behaviour was changed to allow you to change the process' job even if it's already assigned to a job. See the documentation for AssignProcessToJobObject(): https://docs.microsoft.com/en-us/windows/win32/api/jobapi2/nf-jobapi2-assignprocesstojobobject for more information. Otherwise, the sample appears to work correctly: I can spawn processes and assign PIDs to jobs and terminate them. However, the sample does minimal error checking, so I can't tell if any of the other native calls are failing without digging deeper.

My guess is there was a change in how Windows handles jobs between when the book was written and now to make all processes part of some job. AssignProcessToJobObject() was definitely changed, but I'm guessing by default Windows more aggressively assigns jobs to processes.

I'll update the sample to add a note about the change in behaviour.