Groszexxx

A weź, prosze zrób nowy log, bo być może to też będzie rozwiązaniem nurtującego mnie problemu. W zasadzie to myślałem, żeby na test wyłączyć fastboot.

Moze byc ten I:\Mini-WinFE.2014.07.03\Mini-WinFE\WinFE.Project.Output\ISO.ROOT\sources Rownie dobrze może być ten z iso, ktorego z ktorego wczesniej probowales sie zbootowac. Nie ma różnicy.

Powstały log wynikowy spakuj do archiwum, a następnie wyślij go na jakiś hosting, np. MediaFire. Miszel03: Proszę o pełny zestaw raportów FRST (choć w infekcję wątpię, po tylko skanach), bo tamte już nieaktualne, a widzę, że tu trwają również prace z innej dziedziny. ​Przy okazji posprzątałem temat.

Z jakim problemem? Jeżeli przy kompresowaniu masz odmowę dostępu to możesz uruchomić program do kompresowania przez nsudo. Zresztą, to by dowodziło, że coś nie tak jest z uprawnieniami użytkownika, ale to nie chce póki co sie w to zagłębiać. Powiedz ile folder windows będzie ważył po kompresji.

Na forum panuje zasada: jeden problem = jeden temat. Także załóż nowy.

Wrzuć na jakiś hosting, dziwne, żeby takie logi wrzucać na forum. Kto by za to miał zapłacić?!

Tylko First triage Cię interesuje + general. https://www.fixitpc.pl/topic/29344-diagnostyka-samoczynnych-restart%C3%B3w-i-bsod/

Co do punktu 3 to można po prostu uruchomić wprui i stworzyć log co wykonuje się w systemie. Menadżer zadań w windowsie nie podaje rzeczywistych wartości. Jeżeli jest 0% użycia cpu to na pewno tych 0% nie ma, w tym celu lepiej uzyć programu Process Explorer. Te pliki tekstowe są bezużyteczne, załącz całe zrzuty pamięci.

I jak sytuacja?

W temacie do którego sam nawiązałeś masz w poście 3 info o tym, że klucz MpsSvc ma specjalne uprawnienia. Jest tam instrukcja o ręcznej odbudowie. Skoro sprawdziliśmy, że klucz mpsdrv jest w porządku - to skorzystaj z automatu Esetu, o którym info jest w poście 4, on tylko tego klucza nie odtwarza, a on jest poprawny. Powinienem od razu to napisać, ale pomimo dwukrotnego sprawdzenia, żle przeczytałem Twój post i pomyliłem mpsdrv z MpsSvc

Przywracałaś do ustawień fabrycznych? Usuwałaś chrome'a i zainstalowałeś jeszcze raz?

Faktycznie coraz więcej jest dziwnych objawów związanych z planami zasilania po aktualizacjach na w10, niemniej to co opisujesz niezbyt pasuje do objawów. O ile na laptopie faktycznie zrównoważony wcale nie tak rzadko zawodzi - o tyle na desktopie nigdy się z tym nie spotkałem. Dwa różne urządzenia, te same objawy. Obydwa windowsy pobierane z oficjalnego źródła? Nie mam nic do piractwa, ale może trafiłeś na jakieś modyfikowane dystrybucje?

Po kompresji będzie mniej. Takie rzeczy najlepiej uploadować w nocy, myślę, że jedna doba spokojnie wystarczy.

Niestety po opisie nie bardzo mogę coś doradzić. Z takich ogólnych spraw to zacząłbym od przywrócenia systemu do ustawień fabrycznych. Następnie obserwował czy sytuacja uległa poprawia, zwłaszcza, że z czasem zostaną pobrane aktualizacje, więc najlepiej się skupić na obserwacjach świeżo po przywróceniu. Jeżeli od samego początku problem będzie występował - to przynajmniej wiemy, że sytuacja jest niezależna od systemu operacyjnego, a więc automatycznie zależna od sprzętu, a wtedy masz możliwość reklamacji. Coraz więcej dziwnych błędów jest związanych z planem zasilania, spróbuj ustawić na początek maksymalną wydajność.

Chrome > ustawienia > zarządzanie hasłami > autologowanie.

Dziwna sprawa. Spróbujmy sprawdzić czy na pewno chodzi o uprawnienia. Pobierz program Nsudo , rozpakuj go, uruchom. Zaznacz all privilage i uruchom z niego cmd.exe > i w nim wpisz jeszcze raz ww. komendę.

Prawie każdy program do haseł po konfiguracji - tutaj w kontekście jaki przedział znaków (cyfry, małe litery, duze litery, znaki specjalne, znaki interpunkcyjne, spacje, etc.) oraz ile znaków - po w miarę krótkim oszacowaniu - podaje przypuszczalny czas, ktory opiera się na maksymalnym czasie oczekiwania, a nawet jesli nie - to podaje ilosc kombinacji na sekundę. Zamiast zadawać głupie pytania na forum - trzeba po prostu wziąć kartkę i policzyć. Już nie wspomnę, że różnica między 10 znakowym hasłem, a 20 jest znaczna. Temat do kasacji powinien iść ze względu, że jest napisany niedbale.

Poprawiona, zapomniałem zmienić ścieżkę na log, swoja droga mogles sam to wylukać .

Edytowalem powyzszy post, przeczytaj go.

Tak, zaakceptuj. To standardowy tekst. Zresztą, nieważne. W dziennikach zdarzen jest info, ze z woluminami wszystko okej. Niestety, nie znalazłem błędów, które by mnie na coś nakierowały. W takim razie skopiuj cały swój folder windows, spakuj go, a następnie wrzuć na jakiś serwer lub wyślij mi za pomocą ftp'a. Chcę odpalić Twój system w maszynie wirtualnej, bo na razie nie mam żadnych pomysłów, a sprawa wydaję się bardzo ciekawa. Skopiować windows możesz wykorzystując tę metodę: pobierz program shadowspawn Uruchom cmd jako admin, wpisz w nim: cd /d lokalizacja do folderu shadowspawn (tam gdzie znajduje sie plik shadowspawn.exe) Dalej: (utworz na dysku d folder: windows) Zadbaj o wolne miejsce. ShadowSpawn.exe c:\windows q: robocopy q: d:\windows /e /copyall /z /b /r:0 /w:0 /log:d:\log.txt /tee Następnie spakuj go np. programem 7zip.

Czekam na wieści odnośnie sprawdzania integralności plików. Czy jakieś zostały wykryte? Wpisz też profilaktycznie chkdsk c: /f i chkdsk d: /f Generalnie winnym jest, wkleje screena, bo nie chce mi się pisać: Dorzuć mi jeszcze dziennik zdarzeń (sekcja pełne dzienniki zdarzeń) . I cofnijmy się do zmian, które wykonaliśmy z tymi usługami, to był ślepy zaułek, a ja chciałem koniecznie coś na szybko sprawdzić.

Ten log, który mi dałeś, robiłeś z wyłączonymi kartami sieciowymi czy nie? Jest ten sam główny problem co wcześniej, przez około 60 sekund system stoi przy starcie

No i w biosie też nie działa?

Nie, dalej jest źle. 1) Czy zastosowałeś narzędzie do usuwania Avasta ? (Uruchom je w trybie awaryjnym) 2) Czy wyłączyłeś karty sieciowe? Sterowniki avasta dalej są na stosie. Skorzystaj z cleanera, a potem ręcznie sprawdź czy są takie pliki jak: - aswbloga.sys - aswSP.sys -aswSnx.sys -aswVmm.sys -aswbidsha.sys C:\ProgramData\AVAST Software\ - > dalej istnieje. C:\Program Files\AVAST Software\Avast - dalej istnieje Wspomniane wyżej pliki powinny być w C:\WINDOWS\system32\drivers\ Tego jest tyle, ze az mi sie nie chce wypisywać. Weź się przyłóż do roboty. W ogóle go nie usunąłeś! Zwłaszcza, że to on jest tu głównym podejrzanym. Wykonaj te czynności i nowy log wrzuć. Oczywiście mówię o xperf. Edit: Widzę, że się pomyliłeś i nie zamieściłeś ostatniego logu tylko jakiś stary. Z przedwczoraj. Sprawdź to! To jest dokładnie ten sam log co Twój pierwszy.

Nie, z xperf.