mgrzeg

Z podesłanych logów i raportu klaruje się dosyć smutny obraz: masz komputer z procesorem, który nie jest demonem szybkości (AMD E 240 1-rdzeniowy, 1-wątkowy) i obawiam się, że za wiele nie możesz się po nim spodziewać. Masz całkiem dużo pamięci (4 GB), więc przynajmniej nie masz problemu z ciągłym stronicowaniem, ale w sumie system jest sklasyfikowany tak: CPUScore 2,5 D3DScore 5,5 DiskScore 5,7 GraphicsScore 4,2 MemoryScore 4,1 To co można zrobić, to: 1. Wyłączyć Windows Defender - masz pakiet od McAfee + MBA, więc nie potrzebujesz. Kliknij start, w polu wyszukaj wpisz 'windows defender', po czym wybierz proponowany program. Kliknij Narzędzia, później wybierz Opcje i Administrator. Odznacz 'Użyj tego programu'; 2. Wyłączyć Windows Search. Można to zrobić z poziomu Panel sterowania -> programy -> Włącz lub wyłącz funkcje windows. Przyznaję jednak, że poważnie bym się nad tym zastanowił - WSearch w Twoim raporcie zajmuje ~0% czasu procesora, więc jest pomijalne, a wyłączenie pozbawia Cię paru fajnych funkcjonalności; 3. Patrząc na czas DPC wydaje mi się, że niektóre sterowniki mogą nieco blokować komputer (nieszczęsny 1 rdzeń z 1 wątkiem) i zapewne jest to McAfee 4. Możesz pomyśleć nad usunięciem niektórych 'przydasiów' Toshiby, choć i tu zysk nie będzie duży. Zacznij od Windows Defendera. Jeśli to nie pomoże, to IMO następny w kolejce jest McAfee i zrobimy nieco dłuższy test wydajności podczas czynności, które opisujesz, czyli przeglądanie internetu, katalogów na dysku, etc. pod kątem obciążenia sterowników oraz filtrów pracujących w przeglądarce i eksploratorze. m.g.

Po przemyśleniu spróbujmy wszystko zrobić na Twoim XP. 1. Utwórz na dysku c: katalog xperf - c:\xperf 2. Pobierz do utworzonego w pkt 1. katalogu plik wpt_x86.msi z adresu KLIK 3. Korzystając np. z 7-zip 'rozpakuj tutaj' zawartość pliku wpt_x86.msi (czyli wszystkie pliki powinny się znaleźć w katalogu c:\xperf). 4. Uruchom wiersz polecenia, przejdź do katalogu c:\xperf, wykonując polecenie cd c:\xperf po czym wpisz następującą komendę: xbootmgr -trace boot -traceFlags BASE+CSWITCH+DRIVERS+POWER -resultPath C:\xperf i dalej postępuj zgodnie z opisem KLIK - Windows Performance Toolkit, począwszy od punktu 4. (zamiast c:\LOGI masz c:\xperf) Utworzony w ten sposób plik .etl spakuj zipem i shostuj gdzieś (np. speedyshare.com), po czym podaj tu link. m.g.

10 minut to zdecydowanie za długo, nawet biorąc pod uwagę możliwości Twojego komputera. Czy masz dostęp do komputera z Vistą, lub Windows 7 na którym możesz coś zainstalować? m.g.

1. Przygotuj na początek zestaw podstawowych logów OTL + Gmer: KLIK i dołącz je jako załączniki do postu. 2. Po zakończeniu kroku 1 przygotuj także raport monitora wydajności systemu (najlepiej w momencie, w którym zauważasz problem), wpisując w oknie 'Uruchom' (klawisz Win+R) polecenie perfmon /report po zakończeniu tworzenia raportu (ok. 60 sec) wybierz Plik->Zapisz jako i tak utworzony plik .html spakuj zipem i shostuj gdzieś (speedyshare), a w poście podaj link. m.g.

Począwszy od Visty sterowniki ładowane w trybie jądra mają mieć podpis cyfrowy. W przypadku systemów 64-bit ominięcie tego wymagania nie jest takie proste. Z logów wynika, że zdecydowana większość sterowników ma daty powstania na długo przed Vistą, więc pytanie, czy nie ma przypadkiem ich nowszych wersji? Ale zacznijmy od sprawdzenia, o które sterowniki chodzi. 1. Uruchom 'Podgląd zdarzeń' wchodząc do okna 'uruchom' (Win+R) i wpisz eventvwr.msc 2. Przejdź do 'Dzienniki aplikacji i usług'/Microsoft/Windows/CodeIntegrity/Operational 3. Zaznacz wszystkie błędy z prawej strony i z akcji wybierz 'zapisz wybrane zdarzenia'->'tekst (rozdzielany tabulatorami) (*.txt)' 4. Zapisany plik załącz do postu Jako ostateczność można również wyłączyć wymóg podpisanych sterowników trybu jądra, choć czasem problem jest głębszy (np. uszkodzony jest plik .cat), więc zostawmy sobie tę opcję na koniec. m.g.

O, o, właśnie coś takiego, tyle że z fixitpc.pl w tytule Jak mówię - nie jest to bardzo uciążliwe, da się żyć. m.g. Edit: Długo nie musiałem czekać

Nie zgłaszałbym problemu, gdyby problem dotyczył jednego komputera i jednej sieci. Niestety problem mam na kilku różnych komputerach w różnych sieciach (w robocie, w domu, przypadkiem jeszcze gdzieś indziej). Problem nie jest uciążliwy, chociaż przyznaję, że komunikat o wewnętrznym błędzie serwera (AFAIR coś o sterowniku bazy danych - sorry, next time zrobię zrzut) nieco mnie zmartwił i stąd mój post. m.g.

Witam, od mniej więcej tygodnia przyuważyłem problem z serwisem - przechodzenie między stronami zajmuje nawet po kilkanaście sekund. Kilka dni temu zgłosił mi się błąd wewnętrzny serwisu, którego oczywiście nie zanotowałem, ale po kilku chwilach wszystko 'odżyło'. m.g.

To chyba dobra okazja, żeby pobawić się świeżutkim tutkiem przed jego akceptacją i nanieść korekty 1. Przygotuj zatem zgodnie z opisem [KLIK] wymienione w opisie pliki. 2. Po zakończeniu kroku 1 przygotuj także raport monitora wydajności systemu (najlepiej tuż po starcie systemu), wpisując w oknie 'Uruchom' (klawisz Win+R) polecenie perfmon /report po zakończeniu tworzenia raportu (ok. 60 sec) wybierz Plik->Zapisz jako i tak utworzony plik .html spakuj zipem i shostuj gdzieś, a w poście podaj link. 3. Zajrzyj do katalogu c:\windows\minidump i jeśli znajdziesz tam jakieś pliki z ostatniego tygodnia, to również spakuj je zipem i shostuj gdzieś, a w poście podaj link. m.g.

Grisza, przyznaję bez bicia, że nie planowałem tekstu 'analitycznego', a raczej 'pomocnik' dla działów systemowych. Picasso uważa, że lepiej będzie temu tekstowi z innymi tutkami, niż jako wątek przypięty, bo obiecałem jeszcze rozwinięcie tematu o zamknięcie systemu, logowanie oraz 'przymulony' system, choć wszystko bez szczegółów analitycznych. I właśnie ze względu na 'przymulony' scenariusz dobrze jest mieć stack walking. Generalnie chodzi o to, że niektóre providery mogą dostarczać więcej informacji (cały call stack) przy włączonej tej opcji, ale i bez niej można działać. Ja dla 'świętego' spokoju umieściłem ją na samym początku tekstu. W XP w ogóle nie ma tej opcji. W przypadku Vista+ można popatrzeć sobie na stos wywołań i mając dobrze skonfigurowane symbole przyjrzeć się, która funkcja 'waży' najwięcej. O symbolach pisałem sporo na swoim blogu, a call stacku i symbolach m.in. w przypadku procmona, który od kilku lat korzysta z ETW pisałem tu [KLIK], zachęcam do zajrzenia zanim wszystkie komentarze znikną m.g.

100% pewności nie mam, ale wszystko wskazuje na gryzienie się zestawu: Avast + SpyShelter + PC Tools, przy czym sterownik z PC Tools wysypał się (wersja z marca 2011). Odnośnie logów to dają poglądową informację o systemie, bo w dumpie nie wszystko jest (właściwie w Twoim jest tylko stack trace + rejestry + trochę statystyk). Możesz pomyśleć o włączeniu verfiera KLIK na ok. dobę, ale uważaj - to ma skończyć się BSODem i zapewne będzie skutkować spowolnieniem systemu. Ale w sumie najlepiej to jakbyś się zdecydował na jedno z rozwiązań AV, a resztę usunął. m.g.

Zazwyczaj przyczyną C2 są drivery, lub problem z pamięcią. Przydałoby się więcej informacji, a najlepiej sam memory dump. Zobacz w katalogu c:\windows\minidump\ czy coś jest i jak tak, to spakuj wszystko i shostuj gdzieś. Zrób też standardowy zestaw logów (OTL+Extras+Gmer). m.g.

Zastanowię sie jak to ugryźć, sam dosyć często korzystam z xperf na XP. m.g.

Spakuj pliki .dmp z katalogu c:\windows\minidump i shostuj gdzieś, a tu podaj link. Masz problem z dyskiem: więc na pewno będziesz musiał zgłosić się do działu hardware - tam już cię dalej pokierują. Już teraz jednak zatroszcz się o swoje dane i zrób kopię najważniejszych rzeczy. m.g.

W przypadku XP jest nieco bardziej skomplikowanie. W ramach WPT jest pakiet wyłącznie pod Vistę, 7 & 8 (+wersje serwerowe) i nie ma wsparcia dla XP. Poprzednie wersje dawały możliwość zainstalowania WPT np. na Viście i przekopiowania niezbędnych (xperf.exe + perfctrl.dll) plików na XP, obecna wersja xperf.exe już nie działa na XP. Tak jak pisałem - w ramach fixitpc nie ma możliwości hostowania żadnych plików, dlatego nie chciałem komplikować opisu i dawać linków do ćwierć legalnych źródeł, dlatego opis dotyczy wyłącznie Vista+. m.g.

Ta sama procedura. Start systemu podzielony jest na kilka etapów, powyższa metoda zbiera dane z każdego z nich. m.g.

wolsky, pliki z logami to tylko skrót tego, co można wyciągnąć z pliku .etl. Oczywiście wolałbym obejrzeć plik .etl, ale pliki tekstowe poza rozmiarem są dla użytkowników 'bezpieczniejsze', bo widzą co się w nich znajduje i co przekazują innym, do tego publicznie, nie mówiąc już o tym, że na koniec analizy pojawia się informacja o tym, że w środku są informacje 'wrażliwe' i należy być ostrożnym w tym, co się przekazuje innym osobom Dla porównania, w logach przygotowanych przez OTL jest bardzo dużo informacji wrażliwych, w plikach .dmp też jest całkiem sporo. Noszę się już od jakiegoś czasu (oj, pewnie ze 2-3 lata ) z tekstem o xperfie na blogu i jak tylko znajdę trochę czasu, to na pewno coś skrobnę Kto wie, może idąc za ciosem zrobię to niebawem? Jak Picasso zorganizuje Akademię (a co najmniej zamknięte forum dla wybranych pomagaczy i autorów tutków), to obiecuję garść informacji tam wrzucić i poddać pod dyskusję m.g.

Dzięki za komentarz. To mój pierwszy tekst w tym dziale i każda uwaga jest bardzo cenna. Myślałem o uproszczeniu całej procedury, ale niewiele da się zrobić. Xperf nie wymaga instalacji, jednak zgodnie z warunkami licencji nie można go dystrybuować i udostępniać publicznie, więc odpadło przygotowanie pliku.zip z xperfem i kilkoma batchami. Jak zdążyłem zauważyć, nawet Picasso wrzuca zawartość batchy żywcem w tekście postu i nie dodaje załączników do swoich postów, więc nie zamierzam się z tego wyłamywać. Sprawę dodatkowo utrudnia fakt, że nie wiadomo na którym dysku zostanie utworzony katalog xperf, więc bez modyfikacji poleceń przez użytkownika się nie obejdzie. Odnośnie DisablePagingExecutive, to w przypadku XP oraz 32-bitowych wersji Visty i 7, domyślnie ustawione jest na 1. W przypadku 64-bit Vista i 7 domyślnie jest 0 i ustawienie na 1 nie obniża stabilności i bezpieczeństwa systemu. Sama wartość kontroluje, czy nieużywane sterowniki mogą zostać zestronicowane na dysk. Za chwilę dopiszę mimo wszystko powrót do 0. Co do długości i skomplikowania tekstu, to w moim odczuciu nie odbiega od innych tekstów z działu; wszystkie one są raczej dla co najmniej średniozaawansowanych użytkowników i wymagają pewnych umiejętności w korzystaniu z systemu. Z ciekawości spytam: czy próbowałeś przejść tę procedurę i miałeś z czymś problem? m.g.

Nie wiem jaka jest procedura oraz gdzie odbywa się dyskusja odnośnie niezatwierdzonych tekstów, więc wrzucam tu info o nowym tekście w strefie użytkowników. Przy okazji, jak ustawić rozmiar dołączonego do tekstu obrazka? Odnośnie xperf, to szykuję jeszcze drugi tekst odnośnie długich czasów w DPC, o co czasem podejrzewam na forum 'zajęte, wolno działające systemy' i ogólnie analizy spowolnionych systemów (nie tylko z powodu problemów ze sterownikami). Czekam zatem na uwagi i dalszy rozwój sytuacji m.g.

Podziel się plikiem system z \windows\system32\config, może coś znajdziemy. Spakuj zipem i shostuj gdzieś. m.g.

Spróbuj metodę opisaną przez Picasso KLIK

Możesz gdzieś wrzucić dump i pliki rejestru? m.g.

psshutdown jest aplikacją konsolową i do uruchomienia jej użyj cmd. Przy standardowej procedurze (Start->Zamknij system) system się zamyka poprawnie? m.g.

A próbowałeś psshutdown z pakietu Sysinternals Suite? Przy standardowej procedurze (Start->Zamknij system) system się zamyka? m.g.

Jestem w trakcie szykowania jakiegoś tekstu o analizie startu/zamknięcia i w ogóle wydajności, ale na razie może wystarczy kilka punktów. (Uwaga: procedura dla co najmniej średnio-zaawansowanych użytkowników) 1. Zainstaluj Windows Performance Toolkit z pakietu ADK (Windows Assessment and Deployment Kit): - domyślna lokalizacja; - z dostępnych opcji zaznacz tylko Windows Performance Toolkit (+ ewentualnie .NET Framework 4.0, jeśli brak w systemie). 1a. Dla systemu Windows 7 x64 uruchom cmd jako administrator i ustaw poleceniem: REG ADD "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v DisablePagingExecutive -d 0x1 -t REG_DWORD -f Dalej uruchom wszystko tak jak normalnie (z długim startem) i zbierz trochę danych: 2. Utwórz katalog xperf na dysku, który nie będzie analizowany (na którym nie jest zainstalowany system) - widzę, że na e: masz trochę miejsca, więc e:\xperf 3. Uruchom cmd jako administrator i wykonaj polecenie (parametr resultpath należy zastąpić właściwą ścieżką do katalogu utworzonego w pkt. 2): xbootmgr -trace boot -traceflags latency+dispatcher -stackwalk profile+cswitch+readythread -notraceflagsinfilename -postbootdelay 180 -resultpath e:\xperf 4. Zaakceptuj komunikat UAC, poczekaj na uruchomienie ponowne systemu, po czym względnie szybko zaloguj się. Po chwili pojawia się okno z informacją o pozostałym czasie, nie klikaj finish! Po zakończeniu pojawia się komunikat o utworzeniu pliku w odpowiednim katalogu. 5. Uruchom cmd i korzystając z polecenia cd przejdź do katalogu zawierającego plik .etl (utworzonego w pkt. 2 - w twoim przypadku jest to dysk e:). e: cd xperf xperf -i boot_1.etl -o summary.xml -a boot xperf -i boot_1.etl -o pnp.csv -a pnp xperf -i boot_1.etl -o services.csv -a services 6. Pozmieniaj nazwy plików: summary.xml -> summary.txt, pnp.csv -> pnp.txt, services.csv -> services.txt i dołącz do postu. Uwaga do 3. Jeśli po zalogowaniu się do systemu czas oczekiwania na możliwość zrobienia czegokolwiek jest dłuższa niż 3 min (180 sek), to parametr postbootdelay należy zmienić na odpowiednio dłuższy (np. 600 dla 10 min.) Uwaga: Im dłuższy czas ładowania systemu, tym plik boot_1.etl będzie większy, generalnie należy liczyć się z całkiem sporym plikiem (od kilkustet MB do kilku GB), więc dysk na którym będzie tworzony musi mieć odpowiednio dużo wolnego miejsca. m.g.