21.11.2007 02:06 (Ten post był ostatnio modyfikowany: 13.11.2021 02:41 przez Spartan.)
Witam,
Jak wiadomo podczas normalnego działania windowsa, przy wciśnięciu Ctrl+Alt+Del natychmiast wyskakuje nam menedżer zadań. Problem pojawia się wtedy gdy jakiś proces się "przyssie" do procesora i wykorzystuje go na 100%. Pół biedy jeśli taki proces ma priorytet normalny, ale jeśli taki proces ma priorytet wysoki lub czasu rzeczywistego, to już samo otworzenie menedżera jest problemem, nie mówiąc o zamknięciu np. zawieszonego procesu (swoja drogą spora niedoróbka - wtedy gdy menedżer jest najbardziej potrzebny to się nie pojawia).
Czy istnieje taka możliwość, żeby podwyższyć jakoś priorytet Ctrl+Alt+Del, tak żeby menedżer działał zawsze bezproblemowo?
PS.
Nie żebym jakoś baaardzo często musiał z tej kombinacji korzystać , ale czasem fajnie by było mieć możliwość zamknięcia jakiegoś zawieszonego procesu. Np. czasem na niektórych filmach lubi mi się zawiesić subedit, a że standardowo pracuje na priorytecie wysokim, to zamknięcie dziada jest praktycznie niewykonalne (jak raz musiałem go ubić, bo nie chciałem stracić danych z innego programu, to musiałem walczyć ze 20 minut i udało mi się tylko dzięki temu , że zrobiłem kiedyś z nudów program do zawieszania innych programów. Kilkanaście kopii menedżera zadań wyskoczyło oczywiście dopiero jak już było po wszystkim ...)
Ja korzystam z Process Explorera - podobny problem jak Ty z Subedtiem mam z AllPlayerem (nie żebym wolał tego pierwszego).
W wypadku zawieszenia się kompa podczas próby włączenia filmu w Allplayerze wciśnięcie kombinacji ctrl+alt+del = wyskoczenie sporej ilości okienek menadżera zadań (co ciekawe, o ile pamiętam ową trójpalcową kombinację wcisnąłem tylko raz).
W Procces Explorerze (zresztą poznanym dzięki temu forum) wystarczy dać kill process tree (lub samo kill process) i po problemiem.
Ofkoz to nie rozwiązuje Twojego problemu, ale w razie gdyby jednak nie dało się podwyższyć 'priorytetu ctrl+alt+del' jest to jakieś wyjście - szczególnie w wypadku zawieszenia się playera (tak jak u mnie).
21.11.2007 07:16 (Ten post był ostatnio modyfikowany: 13.11.2021 02:25 przez Spartan.)
wystarczy odpalić dowolny z omawianych programów, aby przekonać się, iż uruchamiają się one defaultowo z najwyższym priorytetem (13), przeskakują więc zawsze inne programy, co tu więc podwyższać [wyżej jest tylko priorytet "czasu rzeczywistego" procesora (24) którego wymuszenie przy zawieszeniu komputera pogorszyłoby raczej tylko sprawę]
rozwiązaniem, które zawsze polecam, jest dodanie jednego z nich (oczywiście najlepiej procexp) do autostartu (jako zminimalizowany od pocz. to traya) - mamy bieżący monitoring procesora (to raz), poza tym szansa na wyświetlenie okna działającego cały czas programu w przypadku problemów, po naduszeniu myszką na ten czerwony wtedy kwadracik w rogu, jest duuużo większa, niż wymuszanie dopiero uruchamiania go np. sekwencją klawiszy ctrl+alt+del
jeśli chodzi natomiast o playery - używanie progsów, o których mówicie to porażka jest program, który nie obciąża nigdy praktycznie nic (nawet przy transmisji HDTV), niczego nie wymaga i nigdy się nie wiesza
Do tego celu idealny jest Process Tammer - darmowy program, ktory dziala jako usluga systemowa (ale ma tez klienta GUI) i automatycznie zmniejsza priorytet procesu do niskiego, jesli ten zuzywa np. wiecej niz 90% zasobow CPU przez zdefiniowany okes czasu. Sam Process Tammer ma priorytet wysoki i radzi sobie z takim "zacieciem" idealnie. Uzywalem go z ProgDVB - aplikacja do ogladania DVBS - ktora tez do idealnego dzialania na jednordzeniowym CPU wymaga priorytetu HIGH. Oczywiscie jesli nic innego na kompie sie nie robi, tylko oglada tv, wystarczy normal. Ale jesli dziecko na tv-out oglada bajki a na glownym monitorze nawet sie po www lazi, to wtedy trzeba progowi poprawic priorytet.
Wada Process Tammera jest to, ze "tamuje" wszystkie procesy, poza zdefiniowanymi wyjatkami. Jesli wiec gramy w jakas gre, to trzeba jej proces dodac do listy wyjatkow lub chwilowo wylaczyc dzialanie Process Tammera. Pisalem kiedys na forum tworcy programu, ze przeydalaby sie opcja odwrocenia logiki (tzn. definiowaloby sie tylko programy do monitorowania i "tamowania" a reszta moglaby "zzerac" cpu w 100%. Autor odpisal, ze to dobra koncepcja i ja zaimplementuje w nowej wersji ale tej "duzej" nowej wersji nie ma do dzis (poza poprawkami), wiec dalej jest jakis tam problem.
Ale tak jak pisalem - mechanizm dziala. Spelni dokladnie twoje oczekiwania.
Gnaq napisał(a):Ja korzystam z Process Explorera - podobny problem jak Ty z Subedtiem mam z AllPlayerem (nie żebym wolał tego pierwszego).
Też korzystam z tego świetnego programu, ale niestety w przypadku silnej zawiechy jest u mnie tak samo (nie)skuteczny jak menedżer zadań...
Frank Holman napisał(a):wystarczy odpalić dowolny z omawianych programów, aby przekonać się, iż uruchamiają się one defaultowo z najwyższym priorytetem (13), przeskakują więc zawsze inne programy ...
Trochę już ten temat wybadałem i ... niby faktycznie, ale zauważ, że rodzicem taskmgr.exe jest explorer.exe , który ma priorytet normalny, a i on nie jest początkiem tego łańcuszka, bo za przechwycenie kombinacji Ctrl+Alt+Del odpowiada winlogon.exe. Tak więc, M$ to tak zaprojektował, że chyba nic nie da się zrobić...
Frank Holman napisał(a):[...] wyżej jest tylko priorytet "czasu rzeczywistego" procesora (24) którego wymuszenie przy zawieszeniu komputera pogorszyłoby raczej tylko sprawę
No niekoniecznie, ja odkąd pamiętam zawsze miałem winampa ustawionego na realtime (24) i nie pamiętam, żeby kiedykolwiek przestał grać, co najwyżej w przypadku konkretnej zawiechy nie dało się zmienić utworu, ani zatrzymać odtwarzania
Frank Holman napisał(a):rozwiązaniem, które zawsze polecam, jest dodanie jednego z nich (oczywiście najlepiej procexp) do autostartu (jako zminimalizowany od pocz. to traya) - mamy bieżący monitoring procesora (to raz), poza tym szansa na wyświetlenie okna działającego cały czas programu w przypadku problemów, po naduszeniu myszką na ten czerwony wtedy kwadracik w rogu, jest duuużo większa, niż wymuszanie dopiero uruchamiania go np. sekwencją klawiszy ctrl+alt+del
No było by to jakieś rozwiązanie problemu. Chociaż z tego co pamiętam, to próbowałem już tak kiedyś zrobić z procexp i też nie było tak łatwo.
Frank Holman napisał(a):jeśli chodzi natomiast o playery - używanie progsów, o których mówicie to porażka
Od razu wiedziałem, że tak powiesz Ale subedita już używam tak długo, że nawet nie chciało mi się go zmieniać, zwłaszcza, że dla mnie jest OK. Też nie obciąża systemu, a z tym zawieszaniem, to wszystko zależy od kodeków (odkąd korzystam z ffdshow raczej rzadko).
cin napisał(a):Do tego celu idealny jest Process Tammer - darmowy program, ktory dziala jako usluga systemowa (ale ma tez klienta GUI) [...]
No muszę przyznać, że bardzo ciekawy programik. Zacząłem się nim już bawić ...
Szkoda tylko, że nie odróżnia programów które są zawieszone (w sumie łatwe do wykrycia, bo nie komunikują się z systemem), od tych które podczas normalnego działania obciążają na 100% (jak np. winrar podczas kompresji). Taki progs byłby idealny
T-1000 napisał(a):Szkoda tylko, że nie odróżnia programów które są zawieszone (w sumie łatwe do wykrycia, bo nie komunikują się z systemem), od tych które podczas normalnego działania obciążają na 100% (jak np. winrar podczas kompresji). Taki progs byłby idealny
Tez tak mysle. Moze bym cos takiego napisal
Pytanie, jak pewnie okreslic, czy proces "umarl" (not responding). Moze czegos poszukam na google.
Przetestowałem dokładniej ten programik Process Tamer no i generalnie jest OK, ale jednak z tą skutecznością bywa różnie.
Sprawdza się idealnie w trakcie normalnej pracy na komputerze - nie ma np. takiej sytuacji, że nagle antywirus się zacznie aktualizować i zacznie mi przycinać jakąś grę czy program (co najwyżej te kilka sek. aż Tamer zareaguje).
Jednak jeśli chodzi o programy naprawdę zawieszone (not responding), to pomimo, że Tamer ustawia im priorytet niski, to i tak nic nie daje. Nie jest to wina programu, bo już testowałem różne możliwości, ale po prostu wygląda na to, że zawieszone procesy olewają wszystkie systemowe komunikaty, aż do odwieszenia.
Na szczęście opcja 'forced termination of process' skutecznie ubija takie procesy (a przynajmniej w symulowanych przeze mnie 'zawiechach' )
cin napisał(a):Moze bym cos takiego napisal
Pytanie, jak pewnie okreslic, czy proces "umarl" (not responding). Moze czegos poszukam na google.
Nie wiem czy jest w ogóle możliwe zrobienie naprawdę skutecznego programu. To system powinien mieć wbudowanego tzw. 'watchdoga', który by w przypadku braku komunikacji procesu z systemem przez dajmy na to 10 sek zamrażał taki proces i pozwalał użytkownikowi zdecydować, co z nim zrobić...
Jeśli jednak chcesz spróbować taki program zrobić, to sprawdzanie czy dany proces umarł można by zrobić (tak mi się wydaje ) wysyłając do niego co jakiś czas komunikat i sprawdzać czy odpowie (WM_NULL by się chyba nadawało - jak proces zwróci 0 to jest OK).
Edit.
No i jest jeszcze jeden minus programu - co jeżeli zawiesi się pełnoekranowa gra, która z oczwistych względów jest dodana do ignorowanych w Process Tamerze?
Do przetestowania wczesna wersja alfa programiku wykrywajaca nieodpowidajace aplikacje i zmniejszajaca automatycznie ich priorytet do IDLE.
Testowalem na ProgDVB - po jakis 30 sekundach wykrywal; brak odpowiedzi na WM_NULL-a i zmniejszak priorytet z HIGH na LOW, kontrola na kompem od razu mozliwa.
Pytanie, co z aplikacjami bez petli komunikatow? Albo z grami?
Poki co program monitoruje aplikacje, ktorej dokladna nazwa okna zostanie wpisana jako "Window name". Przycisk Guard oraz CPU usage nie dzialaja. "Priority" pokazuje akltualny priorytet apliakcji monitorowanej, "Hang" powinno sie zmienic na wartosc hang, jak aplikacja nie odpowie przez 500 ms. Wtedy tez km guard powinien wydac dzwiek i obnizyc priorytet.
Potestuj troche T-1000 ze swoimi programi, ktore potrafisz "zawiesic". Nie wiem, czy jest sens rozwijania koncepcji, chociaz u mnie zdaje sie dzialac.
Potestowałem trochę ten Twój programik, działa całkiem nieźle (bym powiedział,że nawet lepiej niż Tamer).
Ja też zrobiłem programik, tyle że do symulowania zawiechy, żeby mieć kontrolę nad tym co się dzieje i nie resetować kompa w przypadku niepowodzenia. Programik jest prościutki - po kliknięciu 'zawieś' zapętla się tracąc komunikację z systemem i zaczyna obciążać procek na 100% z ustawionym wcześniej priorytetem.
Przy priorytecie Normal nie ma oczywiście żadnych problemów. Schody zaczynają się od 'Above Normal'. Twój program po kilku sekundach wykrywa zawieszenie (Tamer już przy Above Normal nie radzi sobie wcale, nie pokazuje nawet 'chmurki', że go spowolnia), i niby ustawia mu priorytet IDLE, ale niestety nie odzyskuje kontroli nad komputerem. Trochę to dziwne, bo przecież sam system kontroluje przydział czasu procesora i nie powinno mieć znaczenia czy dany proces jest zawieszony czy nie.
cin napisał(a):Pytanie, co z aplikacjami bez petli komunikatow? Albo z grami?
To jest niestety spory problem, ale moim zdaniem i tak trzeba najpierw wymyślić lepszy patent, żeby móc odzyskać kontrolę nawet przy ostrych zawiechach (bo to te się najczęściej kończą ręcznym resetem).
Przetestuj cin mojego frozena z załącznika (skompilowany ze wszystkimi bibliotekami, więc nie powinno być nic potrzebne do uruchomienia). Jeśli uda Ci się odzyskać kontrolę przy priorytecie chociaż Above Normal i nieskończonym czasie zawiechy to jest szansa, że można zrobić dobry program do odwieszania (oczywiście nie dotyczy jeśli masz procek dwurdzeniowy - wtedy zamknięcie frozena będzie łatwe, bo jest jednowątkowy, więc będzie obciążać tylko na 50%)
Napisalem podobny program (CPUhogger) ale zapomnialem go wystawic na www. Dziala pewnie tak samo - ustawia sobie priorytet HIGH a potem idzie w jakies kilkadziesiat sekund w petle. Zeby nie robic resetu ta petla jest jednak skonczona.
U mnie moj hogger po zmianie priorytetu na IDLE pozwalal na odzyskanie kontroli. Twojego frozen-a przetestuje jak wroce do domu - jestem teraz w Austrii.
Dodaj we frozenie opcje zawieszania z priorytetem IDLE - powinien wtedy nie blokowac systemu.
Czy moj guard napewno zmienia twojemu frozenowi priorytet? Jest BEEP a potem guard wyswietla IDLE zamast wczesniej wybranego dla frozena priorytetu?
Ja zauwazylem, ze co prawda guard czasem wychwytywal "not responding" dosyc pozno, ale jak juz wychwycil, to zaraz po zmianie priorytetu na IDLE dalo sie dzialac w systemie.
EDIT: Jak ty symulujesz zawieche? Udostepnij kawalek kodu. Mimo, ze moj guard zmienia priorytet, to jednak dalej jest starsznie mulowato.
Nie moge teraz nic zdebugowac, test zrobilem tylko za pomoca obu exec-ow.
To znaczy w moim frozenie jest do wyboru, czy ta pętla ma trwać minutę (w sam raz do szybkiego przetestowania danego sposobu) czy w nieskończoność - do sprawdzania, czy w ogóle da się opanować sytuację przy wysokim priorytecie w jakimkolwiek czasie (oczywiście w przypadku niepowodzenia konieczny ręczny reset).
cin napisał(a):Dodaj we frozenie opcje zawieszania z priorytetem IDLE - powinien wtedy nie blokowac systemu.
Mogę dodać, ale co to za zawieszanie z priorytetem IDLE ? Z resztą mój frozen przy priorytecie normal nie blokuje jakoś poważnie systemu, odczuwa się spowolnienie działania, ale kontrola nad systemem jest.
cin napisał(a):Czy moj guard napewno zmienia twojemu frozenowi priorytet? Jest BEEP a potem guard wyswietla IDLE zamast wczesniej wybranego dla frozena priorytetu?
Tak, Twój guard reaguje prawie natychmiast. Co 1-2 sek przedziera się BEEP (ale nie brzmi tak jak powinien tylko jest trochę urywany), oraz wyświetla IDLE. Kontroli nad systemem jednak nie ma... Frozen nic sobie z tego IDLE nie robi :|
cin napisał(a):EDIT: Jak ty symulujesz zawieche? Udostepnij kawalek kodu. Mimo, ze moj guard zmienia priorytet, to jednak dalej jest starsznie mulowato.
Nie moge teraz nic zdebugowac, test zrobilem tylko za pomoca obu exec-ow.
Z Twoim guardem zawiechę symuluje jak na screenie w załączniku. Mój frozen zawiesza się wpadając w zwykła pętlę for (sprawdza tylko ile czasu upłynęło, żeby wyjść z pętli jeśli ktoś chce zawieszać tylko przez minutę). Dzięki temu (tak jak naprawdę zawieszony program) w czasie zawiechy nie reaguje kompletnie na nic...
Robiłem też inne próby z Tamerem i doprowadzałem do zawieszenia firewalla Kerio. Efekt jest taki sam. Oba programy przypisują zawieszonym programom priorytet IDLE, co mogę sprawdzić w trakcie zawiechy (z trudem) w process explorerze, ale mimo wszystko całkowicie zawieszone programy działają tak, jak by priorytet się nie zmienił (aż do odwieszenia).
Z moich obserwacji wynika, że priorytet całkowicie zawieszonego programu się nie zmienia, nawet jeśli miał on priorytet normal. Co prawda przy normalu kontrola nad systemem jest, ale jeśli uruchomię wtedy jakiś mocno obciążający program z priorytetem IDLE, to nie dostaje on w ogóle czasu procesora, a przecież gdyby priorytet zawieszonego programu faktycznie się zmieniał na IDLE, to oba programy (uruchomiony przeze mnie oraz zawieszony) powinny dostawać po 50% mocy procka...
Z opanowaniem Twojego hoggera też nie mam problemu. W ogóle jakoś zbyt łatwo z nim idzie Mogę go zamknąć po prostu klikając PPM na jego ikonkę na pasku zadań i Zamknij. Trwa to co prawda 10-20 sekund, ale jednak pozwala się zamknąć, więc chyba jednak nie do końca traci komunikację z systemem. Z pomocą guarda odzyskanie kontroli jest praktycznie natychmiastowe.
Mój frozen też jest napisany w C++ tyle, że ja używam C++ Buildera Borlanda (raczej nie powinno to odgrywać tak dużej roli). Tak sobie pomyślałem, że jednak może być jeden szczegół, którym się różnią nasze 'zawieszacze'. Czy Ty ustawiasz również priorytet wątku głównego, czy tylko dla całej aplikacji? Bo ja w każdym wypadku dla wątku głównego ustawiam priorytet THREAD_PRIORITY_TIME_CRITICAL (nawet jeśli dla całej aplikacji jest normal). Tak wygląda u mnie kod dla ustawiania poszczególnych priorytetów :
Kod:
//dla normal
SetPriorityClass(GetCurrentProcess(), NORMAL_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
//dla above normal
SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
//dla high
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);
Dzięki temu nawet jeśli odpaliłby się jakiś dodatkowy wątek (czasem tworzą się jakieś bzdurne samoczynnie) to nie ma szans się przebić. Jedynym działającym we frozenie podczas zawieszenia wątkiem jest wątek główny. Spróbuj tak dać w hoggerze i zobaczymy, jak wtedy będzie działać.
Mam tym razem prośbę do kogoś dysponującego procesorem 2 rdzeniowym - niech ktoś przetestuje frozena i da znać, czy są jakieś problemy z jego zamknięciem podczas zawiechy (priorytet 'above normal' lub 'high').
PS.
Cin, a jak Tobie szło z zamknięciem zawieszonego frozena? Guard pomagał coś, czy nic tak jak u mnie? (u mnie tak jest z każdym naprawdę zawieszonym programem - ustawianie priorytetu nic nie daje)
Nie pomagal, ale to co napisales tlumaczy przyczyne. Zadne aplikacje nie ustawiaja THREAD_PRIORITY_TIME_CRITICAL. Przesadziles
Mysle, ze odpornosc na HIGH wystarcza. ZADEN proces uzytkownika nie powinien miec tpriorytetu TIME_CRITICAL. Prawdziwa aplikacja ProgDVB, ktorej w trybie high po przywieszeniu wylaczanie zajmuje co najmniej kilka minut jest poprawnie ustawiana przez Guarda w ciagu gora kilku-nastu sekund. Co do tego, ze ustawiles tak wysoki priorytet dla threda - musialbym zajrzec, czy Guard nie moglby "przeleciec" wszystkich watkow procesu i im tez zmniejszyc priorytet.
Wersja 0.2 KMGuard-a radzi sobie z procesami o priorytecie < REALTIME. Priorytet glownego watku moze byc typu realitime. Jesli proces i watek sa realtime system totalnie nie obsluguje niczego (mysz stoi, zero uaktualnien ekranu, zadne timery nie wywoluja sie w programach).
Co zmienilem? Otoz KMGuard oraz jego glowny watek dostaja priorytet time-critical a do tego zawieszonemu procesowi zmniejsza priorytet na IDLE oraz robi to samo z wszystkimi watkami tego procesu.
Jesli glowny watek/process kmguard nie ma realtime, to wtedy nie jest mozliwe wychwycenie zawieszenia frozen-a, ktory ustawia swojemu watkowi realtime.
Mimo wszystko mysle, ze przypadek realtime moglibysmy sobie darowac. Ale potestuj T-1000 jakis realnie zawieszjacy ci maszyne soft a nie pisz frozen-ow, co uzywaja real-time.
Witam ponownie, ostatnio trochę mało czasu miałem i dopiero zajrzałem do tematu.
cin napisał(a):[...] Przesadziles
Mysle, ze odpornosc na HIGH wystarcza. ZADEN proces uzytkownika nie powinien miec tpriorytetu TIME_CRITICAL.
Jeśli chodzi o procesy to masz rację, ale co do wątków, to jest to przecież tylko priorytet wewnątrz danej aplikacji, więc ma to tylko takie znaczenie, że żaden inny wątek we frozenie nie dostanie czasu procesora.
TIME_CRITICAL dla wątków jest często wykorzystywany w wielowątkowych aplikacjach. Np. taki winamp w trakcie odtwarzania muzyki ma 12 wątków z czego aż 4 mają taki priorytet (podczas gdy cały proces winampa ma normalny).
Twojego guarda niestety nie mogę przetestować w rzeczywistych warunkach, bo akurat te programy/gry co mi się wieszają nie posiadają okna. Jutro popróbuje go przetestować z czym będę mógł. W każdym razie zawieszenie np. Kerio w moim przypadku jest tak samo ciężkie (albo może i cięższe) do pokonania jak frozen ustawiony na High...
, ale czasem fajnie by było mieć możliwość zamknięcia jakiegoś zawieszonego procesu. Np. czasem na niektórych filmach lubi mi się zawiesić subedit, a że standardowo pracuje na priorytecie wysokim, to zamknięcie dziada jest praktycznie niewykonalne (jak raz musiałem go ubić, bo nie chciałem stracić danych z innego programu, to musiałem walczyć ze 20 minut 
i udało mi się tylko dzięki temu , że zrobiłem kiedyś z nudów program do zawieszania innych programów. Kilkanaście kopii menedżera zadań wyskoczyło oczywiście dopiero jak już było po wszystkim ...)
Ale subedita już używam tak długo, że nawet nie chciało mi się go zmieniać, zwłaszcza, że dla mnie jest OK. Też nie obciąża systemu, a z tym zawieszaniem, to wszystko zależy od kodeków (odkąd korzystam z ffdshow raczej rzadko).