по хендлу процесса определить Suspended State

Как имея хэндл процесса определить является ли он в Suspended State или нет ?
Ничего другого пока не пришло в голову как определив косвенно - его HandlesCount , пока при тестировании нескольких процессов это себя оправдывает , м.б. есть более "железобетонный" метод ?)

 

Эм, не понял, а что это вообще такое - Suspended State для процесса?

 

CreateProcess(..., CREATE_SUSPENDED,...)

 

Посмотри _KTHREAD и _KTHREAD_STATE возможно оно.

Код (Text):

1. /
2. // Thread scheduling states.
3. //
4.  
5. typedef enum _KTHREAD_STATE {
6.     Initialized,
7.     Ready,
8.     Running,
9.     Standby,
10.     Terminated,
11.     Waiting,
12.     Transition,
13.     DeferredReady,
14.     GateWait
15. } KTHREAD_STATE;
16.  
17.  
18. typedef struct _KTHREAD {
19.  
20.     //
21.     // The dispatcher header and mutant listhead are fairly infrequently
22.     // referenced.
23.     //
24.  
25.     DISPATCHER_HEADER Header;
26.     LIST_ENTRY MutantListHead;
27.  
28.     //
29.     // The following fields are referenced during context switches and wait
30.     // operatings. They have been carefully laid out to get the best cache
31.     // hit ratios.
32.     //
33.  
34.     PVOID InitialStack;
35.     PVOID StackLimit;
36.     PVOID KernelStack;
37.  
38.     KSPIN_LOCK ThreadLock;
39.     union {
40.         KAPC_STATE ApcState;
41.         struct {
42.             UCHAR ApcStateFill[KAPC_STATE_ACTUAL_LENGTH];
43.             BOOLEAN ApcQueueable;
44.             volatile UCHAR NextProcessor;
45.             volatile UCHAR DeferredProcessor;
46.             UCHAR AdjustReason;
47.             SCHAR AdjustIncrement;
48.         };
49.     };
50.  
51.     KSPIN_LOCK ApcQueueLock;
52.  
53. #if !defined(_AMD64_)
54.  
55.     ULONG ContextSwitches;
56.     volatile UCHAR State;
57.     UCHAR NpxState;
58.     KIRQL WaitIrql;
59.     KPROCESSOR_MODE WaitMode;
60.  
61. #endif
62.  
63.     LONG_PTR WaitStatus;
64.     union {
65.         PKWAIT_BLOCK WaitBlockList;
66.         PKGATE GateObject;
67.     };
68.  
69.     BOOLEAN Alertable;
70.     BOOLEAN WaitNext;
71.     UCHAR WaitReason;
72.     SCHAR Priority;
73.     UCHAR EnableStackSwap;
74.     volatile UCHAR SwapBusy;
75.     BOOLEAN Alerted[MaximumMode];
76.     union {
77.         LIST_ENTRY WaitListEntry;
78.         SINGLE_LIST_ENTRY SwapListEntry;
79.     };
80.  
81.     PRKQUEUE Queue;
82.  
83. #if !defined(_AMD64_)
84.  
85.     ULONG WaitTime;
86.     union {
87.         struct {
88.             SHORT KernelApcDisable;
89.             SHORT SpecialApcDisable;
90.         };
91.  
92.         ULONG CombinedApcDisable;
93.     };
94.  
95. #endif
96.  
97.     PVOID Teb;
98.     union {
99.         KTIMER Timer;
100.         struct {
101.             UCHAR TimerFill[KTIMER_ACTUAL_LENGTH];
102.  
103.             //
104.             // N.B. The following bit number definitions must match the
105.             //      following bit field.
106.             //
107.             // N.B. These bits can only be written with interlocked
108.             //      operations.
109.             //
110.    
111. #define KTHREAD_AUTO_ALIGNMENT_BIT 0
112. #define KTHREAD_DISABLE_BOOST_BIT 1
113.    
114.             union {
115.                 struct {
116.                     LONG AutoAlignment : 1;
117.                     LONG DisableBoost : 1;
118.                     LONG ReservedFlags : 30;
119.                 };
120.        
121.                 LONG ThreadFlags;
122.             };
123.         };
124.     };
125.  
126.     union {
127.         KWAIT_BLOCK WaitBlock[THREAD_WAIT_OBJECTS + 1];
128.         struct {
129.             UCHAR WaitBlockFill0[KWAIT_BLOCK_OFFSET_TO_BYTE0];
130.             BOOLEAN SystemAffinityActive;
131.         };
132.  
133.         struct {
134.             UCHAR WaitBlockFill1[KWAIT_BLOCK_OFFSET_TO_BYTE1];
135.             CCHAR PreviousMode;
136.         };
137.  
138.         struct {
139.             UCHAR WaitBlockFill2[KWAIT_BLOCK_OFFSET_TO_BYTE2];
140.             UCHAR ResourceIndex;
141.         };
142.  
143.         struct {
144.             UCHAR WaitBlockFill3[KWAIT_BLOCK_OFFSET_TO_BYTE3];
145.             UCHAR LargeStack;
146.         };
147.  
148. #if defined(_AMD64_)
149.  
150.         struct {
151.             UCHAR WaitBlockFill4[KWAIT_BLOCK_OFFSET_TO_LONG0];
152.             ULONG ContextSwitches;
153.         };
154.  
155.         struct {
156.             UCHAR WaitBlockFill5[KWAIT_BLOCK_OFFSET_TO_LONG1];
157.             volatile UCHAR State;
158.             UCHAR NpxState;
159.             KIRQL WaitIrql;
160.             KPROCESSOR_MODE WaitMode;
161.         };
162.  
163.         struct {
164.             UCHAR WaitBlockFill6[KWAIT_BLOCK_OFFSET_TO_LONG2];
165.             ULONG WaitTime;
166.         };
167.  
168.         struct {
169.             UCHAR WaitBlockFill7[KWAIT_BLOCK_OFFSET_TO_LONG3];
170.              union {
171.                  struct {
172.                      SHORT KernelApcDisable;
173.                      SHORT SpecialApcDisable;
174.                  };
175.          
176.                  ULONG CombinedApcDisable;
177.              };
178.         };
179.  
180. #endif
181.  
182.     };
183.  
184.     LIST_ENTRY QueueListEntry;
185.  
186.     //
187.     // The following fields are accessed during system service dispatch.
188.     //
189.  
190.     PKTRAP_FRAME TrapFrame;
191.     PVOID CallbackStack;
192.     PVOID ServiceTable;
193.  
194. #if defined(_AMD64_)
195.  
196.     ULONG KernelLimit;
197.  
198. #endif
199.  
200.     //
201.     // The following fields are referenced during ready thread and wait
202.     // completion.
203.     //
204.  
205.     UCHAR ApcStateIndex;
206.     UCHAR IdealProcessor;
207.     BOOLEAN Preempted;
208.     BOOLEAN ProcessReadyQueue;
209.  
210. #if defined(_AMD64_)
211.  
212.     PVOID Win32kTable;
213.     ULONG Win32kLimit;
214.  
215. #endif
216.  
217.     BOOLEAN KernelStackResident;
218.     SCHAR BasePriority;
219.     SCHAR PriorityDecrement;
220.     CHAR Saturation;
221.     KAFFINITY UserAffinity;
222.     PKPROCESS Process;
223.     KAFFINITY Affinity;
224.  
225.     //
226.     // The below fields are infrequently referenced.
227.     //
228.  
229.     PKAPC_STATE ApcStatePointer[2];
230.     union {
231.         KAPC_STATE SavedApcState;
232.         struct {
233.             UCHAR SavedApcStateFill[KAPC_STATE_ACTUAL_LENGTH];
234.             CCHAR FreezeCount;
235.             CCHAR SuspendCount;
236.             UCHAR UserIdealProcessor;
237.             UCHAR CalloutActive;
238.  
239. #if defined(_AMD64_)
240.  
241.             BOOLEAN CodePatchInProgress;
242.  
243. #elif defined(_X86_)
244.  
245.             UCHAR Iopl;
246.  
247. #else
248.  
249.             UCHAR OtherPlatformFill;
250.  
251. #endif
252.  
253.         };
254.     };
255.  
256.     PVOID Win32Thread;
257.     PVOID StackBase;
258.     union {
259.         KAPC SuspendApc;
260.         struct {
261.             UCHAR SuspendApcFill0[KAPC_OFFSET_TO_SPARE_BYTE0];
262.             SCHAR Quantum;
263.         };
264.  
265.         struct {
266.             UCHAR SuspendApcFill1[KAPC_OFFSET_TO_SPARE_BYTE1];
267.             UCHAR QuantumReset;
268.         };
269.  
270.         struct {
271.             UCHAR SuspendApcFill2[KAPC_OFFSET_TO_SPARE_LONG];
272.             ULONG KernelTime;
273.         };
274.  
275.         struct {
276.             UCHAR SuspendApcFill3[KAPC_OFFSET_TO_SYSTEMARGUMENT1];
277.             PVOID TlsArray;
278.         };
279.  
280.         struct {
281.             UCHAR SuspendApcFill4[KAPC_OFFSET_TO_SYSTEMARGUMENT2];
282.             PVOID BBTData;
283.         };
284.  
285.         struct {
286.             UCHAR SuspendApcFill5[KAPC_ACTUAL_LENGTH];
287.             UCHAR PowerState;
288.             ULONG UserTime;
289.         };
290.     };
291.  
292.     union {
293.         KSEMAPHORE SuspendSemaphore;
294.         struct {
295.             UCHAR SuspendSemaphorefill[KSEMAPHORE_ACTUAL_LENGTH];
296.             ULONG SListFaultCount;
297.         };
298.     };
299.  
300.     LIST_ENTRY ThreadListEntry;
301.     PVOID SListFaultAddress;
302.  
303. #if defined(_WIN64)
304.  
305.     LONG64 ReadOperationCount;
306.     LONG64 WriteOperationCount;
307.     LONG64 OtherOperationCount;
308.     LONG64 ReadTransferCount;
309.     LONG64 WriteTransferCount;
310.     LONG64 OtherTransferCount;
311.  
312. #endif
313.  
314. } KTHREAD, *PKTHREAD, *PRKTHREAD;

 

как мне это может помочь из ring3 ?

 

karabas_barabas
SystemProcessesAndThreadsInformation. Проверяйте State и WaitReason потока.

 

годный вариант вцелом - делать проверку если поток в процессе один +

по идее мой вариант также имеет право на жизнь , когда процесс в suspended state у него нет ни одного открытого хэндла

 

karabas_barabas
Вам же уже сказали, что нет такого понятия suspended state применительно к процессу.

 

ProcessHandleCount.

 

а я на этом и не настаивал )

остановился именно на этом, т.к. у такого процесса не может быть открытых хэндлов

 

karabas_barabas

Я к тому, что постановка задачи неоднозначна. Если создать процесс, дать его потоку поработать, а потом тормознуть этот поток, что должна возвращать функция IsProcessSuspended ? А если процесс создал пять потоков, и все их тормознуть?

 

ну это все имеет место быть , я особо то и не надеялся когда топик создавал, что можно вот однозначно так определить напрямую, и тем более корректно говорить что процесс в suspended state , просто мне было так проще объяснить суть моего вопроса )
проблема решилась через NtQueryInformationProcess(..., ProcessHandleCount, ... ) - до ResumeThread основной нити новосозданного процесса, кол-во его открытых хэндлов, соответственно, зероу.

 

l_inc

Задача более чем чёткая:

Студентег..

 

LightMoon
Факт создания процесса с этим флагом никак не влияет на количество его хендлов в произвольный момент времени.

 

почему же ? что может заставить процесс открыть хэндл в таком состоянии (не выполнив конечно же resumethread)? даже если сильно захотеть как этому процессу возможно присвоить открытый хэндл...

 

karabas_barabas
Во-первых, можно как раз выполнить тот же ResumeThread, потом когда-нибудь опять SuspendThread (где в условии оговаривается, считается ли процесс в таком случае приостановленным или нет?).
Во-вторых, DuplicateHandle элементарно присваивает хэндлы чужому процессу.
В-третьих... да мульйон примеров. Скомпилируйте, запустите и считайте хэндлы:

Код (Text):

1. format PE GUI 4.0
2. include 'win32a.inc'
3.  
4. start:
5.     invoke GetModuleFileName,NULL,mypath,MAX_PATH
6.     mov dword[startupinfo.cb],sizeof.STARTUPINFO
7.     invoke CreateProcess,mypath,NULL,NULL,NULL,FALSE,CREATE_SUSPENDED,NULL,NULL,startupinfo,processinfo
8.     invoke CreateRemoteThread,[processinfo.hProcess],NULL,0,newthread,NULL,0,NULL
9.     invoke CloseHandle,eax
10.     invoke CloseHandle,[processinfo.hThread]
11.     invoke CloseHandle,[processinfo.hProcess]
12. ret
13.  
14. newthread: retn 4
15.  
16. data import
17.     library kernel32,'kernel32.dll'
18.    
19.     import kernel32,\
20.             CreateProcess,'CreateProcessA',\
21.             GetModuleFileName,'GetModuleFileNameA',\
22.             CloseHandle,'CloseHandle',\
23.             CreateRemoteThread,'CreateRemoteThread'
24. end data
25.  
26. section '.bss' readable writable
27. startupinfo STARTUPINFO <>
28. processinfo PROCESS_INFORMATION <>
29. mypath rb MAX_PATH

 

l_inc

Нужно определить что процесс не запущен на исполнение, а не состояние текущее его потоков. Посему значение числа описателей меньше некоторого числа будет однозначно говорить, что процесс не стартовал. И эти описатели не закрываются(например порт csrss).

Это создание дополнительных обьектов, а не их описателей в запускаемом процессе. Считать обьекты не предлагалось. Запустите хоть стопяцот потоков, число описателей не изменится.

 

LightMoon

Это Ваше додумывание задачи. В исходной постановке этого не было. Исходная постановка говорит о неполном понимании вопроса автором. Поэтому важно не додумывать задачу так, чтобы она имела смысл, а пояснить, почему она его не имеет.

Да неужели? А тот факт, что поток создаётся без флага CREATE_SUSPENDED, ни о чём не говорит?

 

l_inc

Не говорит. Создание такого потока эквивалентно созданию второго остановленного треда и ресуму первого. Само по себе создание обьекта не увеличивает число описателей.

В исходной формулировке небыло, но далее тс уточнил CREATE_SUSPENDED. И вообще если вам так охота поспорить, подкину гуан на вентилятор - поток простаивает не только когда он в саспенде. Простой бывает и на уровне шедулера, это не большой длительности квантование, ожидание на обьектах(к примеру WaitFor*Object), ожидание доставки сообщений в шадове, ожидание доставки апк, непосредственно делай(Sleep*) etc. Что из этого считать работой потока(именно работой и простоем, а не константой в трединфо) ?

 

LightMoon

Ну и... Дальше выводы какие-нибудь будут? Поток начал исполняться, прошёл инициализацию... Хэндлов не прибавится?

Покажите мне, где я утверждал обратное. Само по себе создание объекта потока достигается и с флагом CREATE_SUSPENDED. Если бы речь была о самом по себе создании объекта, я бы не указывал специально на отсутствие этого флага.

Не понимаю, что здесь имеется в виду. Для меня это пояснение — бессмысленный набор слов. В любом случае как раз константа (см. пост #6) и указывает на причину простоя потока.