mgrzeg

Witam, czy problem jeszcze się utrzymuje? m.g.

Nie ma takiej prostej opcji. Powiem więcej - szanse na 100% powodzenie operacji IMO są zerowe. Głównie dlatego, że zainstalowane aplikacje trzymają w rejestrze oraz plikach konfiguracyjnych i wewnętrznych bazach danych zaszyte na sztywno ścieżki, w których występuje G:, więc najszybszy i najprostszy sposób to pełna reinstalacja systemu. m.g.

Mając w napędzie dvd płytę instalacyjną (z SP3) uruchom z wiersza poleceń: sfc /scannow Jeśli jednak nie masz płyty, to najprościej chyba będzie skopiować plik winhttp.dll z katalogu C:\WINDOWS\system32\dllcache do C:\WINDOWS\system32 m.

subst to proste polecenie, które niestety tylko na chwilkę rozwiązuje Twój problem - po restarcie dysk c: znowu zniknie i Twój program(y) znowu nie będzie działać Możesz oczywiście pogodzić się z tym i po każdym zalogowaniu dodawać sobie tę literkę (nawet to zautomatyzować dodając plik .bat zawierający powyższe polecenie do autostartu), ale w dłuższej perspektywie to bardzo słabiutkie rozwiązanie. Tak jak pisałem wyżej - obawiam się, że nie ominie Cię reinstalacja systemu, zmiana literki dla dysku systemowego nie należy do najłatwiejszych i szanse na to, że po takiej operacji wszystkie aplikacje będą Ci działać poprawnie są praktycznie zerowe m.g.

Poganianie i dopominanie się o odpowiedź nie ma sensu - odpowiadamy wtedy, kiedy mamy taką możliwość i mamy coś do napisania. Ponadto, jeśli chcesz coś dodać do swojej wypowiedzi, to skorzystaj z opcji 'Edytuj' dostępnej pod postem. Łączę posty i usuwam zbędny. Z załączonego pliku tekstowego jako wstępnego winowajcę można wskazać plik winhttp.dll, jednak brakuje jego pełnej ścieżki. Sprawdź zatem, czy nie ma go w katalogu zawierającym plik CFOSSPEED-V964.EXE (jak sądzę C:\Documents and Settings\DawidJ1906\Pulpit\) i jeśli jest, to zmień jego nazwę na winhttp.old. Podobnie sprawdź kolejne katalogi znajdujące się w ścieżce systemowej: C:\Program Files\WinRAR\ C:\Program Files\ATI Technologies\ATI Control Panel\ Na samym końcu, jeśli nie znajdziesz w żadnym z powyższych katalogów pliku winhttp.dll, to zajrzyj do C:\WINDOWS\system32\ i tu zmień nazwę pliku z winhttp.dll na winhttp.old, po czym uruchom ponownie program. m.g.

Chodzi o program, który przestał działać; dump jest ok. No cóż, ja nie znam bezbolesnej metody zmiany literki dla dysku systemowego. Można teoretycznie pobawić się diskpartem [KLIK], zmienić w rejestrze G: na C: zaczynając od \DosDevices\G: w HKLM\SYSTEM\MountedDevices, później powtórzyć to dla innych wystąpień w rejestrze, ale osobiście nie polecałbym Ci tej ścieżki, a raczej reinstalację systemu, lub pogodzenie się z tym, że część programów nie będzie działać poprawnie. Spytam jeszcze - a co w tej chwili występuje jako c:? Może jeśli jest wolne, to spróbuj poprzez cmd dodać subst c: g:\ i ponownie uruchomić program, może da się oszukać m.

Witam, spróbuj przygotować log .dwi oraz zrzut pamięci dla któregoś z programów zgodnie z opisem [KLIK] m.g.

Pewności nie mam, ale wygląda na to, że program próbuje poprzez WMI dostać się do dysku c:, jednak bez powodzenia i stąd "Not found". Czemu służyło stawianie systemu na dysku G? m.g.

Możesz mi jeszcze podrzucić dwa pliki? G:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll oraz G:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll Spakuj oba .zipem i wrzuć na speedy.sh m.

Próbowałeś kilka razy? Czasem procdump z niewyjaśnionych dla mnie przyczyn nie generuje zrzutu pomimo ewidentnego padu aplikacji. Jeśli jednak nie powstanie zrzut przy żadnym z uruchomień, zrób zrzut wyjątków pierwszego rodzaju (po -e jest 1): procdump.exe -e 1 -ma -w "dayz whitelister (x64-x86).exe" m.g.

Witam, przyda się pełny zrzut pamięci procesu. Poniżej krótki opis. Uruchomienie procdump w trybie oczekiwania: 1. Pobierz procdump [KLIK] 2. Utwórz na dysku katalog c:\dumps i wypakuj procdump.exe do tego katalogu. 3. Uruchom wiersz poleceń (Start-> w polu 'wyszukaj programy i pliki' wpisz cmd.exe) 4. Zmień katalog bieżący na c:\dumps cd c:\dumps 5. Uruchom procdump w trybie oczekiwania na dayz whitelister (x64-x86) procdump.exe -e -ma -w "dayz whitelister (x64-x86).exe" 6. Dopiero w tym momencie spróbuj uruchomić dayz whitelister (x64-x86) i poczekaj, aż pojawi się komunikat błędu. Plik zrzutu (.dmp) spakuj, wrzuć na onedrive, dropbox, lub speedy.sh i w odpowiedzi daj link. m.

Witam na forum, zmień nazwę pliku D:\War Thunder\XINPUT9_1_0.dll na D:\War Thunder\XINPUT9_1_0.old i uruchom ponownie grę. m.g.

Wygląda na to, że program ładuje dynamicznie bibliotekę d3d11.dll, która pochodzi z pakietu DirectX11, niedostępnego na Windows XP. W tablicy importów nie widzę jawnego odniesienia do d3d11, ale jak pisałem - może być ładowana w runtime i bez niej po prostu nie będzie działać. Spróbuj zmienić nazwę tego pliku z C:\WINDOWS\system32\d3d11.dll na C:\WINDOWS\system32\d3d11.old i uruchomić ponownie program. W przypadku błędu braku pliku ('File not found') -> po zabawie, gra nie zadziała na Windows XP i jedyna opcja to zainstalowanie gry na nowszym systemie (Vista+). m.g.

Dlaczego od razu do piekieł! Jak pisałem - często rzut oka na call stack w procmonie już dużo daje, do tego lista driverów z nirsofta i powinno być ok ) m.

Spróbuj ponownie zainstalować DirectX 9.0c [KLIK]. O ile się nie mylę, XINPUT9_1_0.dll wchodzi w skład dystrybucji dla XP. m.

Przyda się zrzut pamięci, pliki wer też by coś pomogły, ale lepiej od razu wziąć się za najważniejsze. Poniżej krótka procedura. Uruchomienie procdump w trybie oczekiwania: 1. Pobierz procdump [KLIK] 2. Utwórz na dysku katalog c:\dumps i wypakuj procdump.exe do tego katalogu. 3. Uruchom wiersz poleceń (Start-> w polu 'wyszukaj programy i pliki' wpisz cmd.exe) 4. Zmień katalog bieżący na c:\dumps cd c:\dumps 5. Uruchom procdump w trybie oczekiwania na Railworks procdump.exe -e -ma -w "railworks.exe" 6. Dopiero w tym momencie spróbuj uruchomić Railworks i poczekaj, aż pojawi się komunikat błędu. Plik zrzutu (.dmp) spakuj, wrzuć na dropbox, lub onedrive (albo w ostateczności speedy.sh) i w odpowiedzi daj link.

Dzięki Groszexxx, tak coś mi nos podpowiadał problemy z dyskiem, głównie za sprawą długich czasów odczytu, ale nie przyjrzałem się temu bliżej. No nic - zobaczymy co pomoże wymiana dysku. m.

Dumpy, które podesłałeś poprzednio pochodzą z trybu użytkownika i nie widać w nich nic, z tego co dzieje się niżej, czyli w trybie jądra. W zasadzie każdy sterownik trybu jądra może być podejrzany o wraże działanie, więc najprostsza metoda, to usuwanie po kolei sterowników firm trzecich, które mogą sprawiać problemy. Można zacząć od przejrzenia listy wszystkich, korzystając z DriverView [KLIK], uruchomić procmon i podglądać call stack dla wspomnianych aplikacji [zachęcam do lektury mojego tekstu sprzed równo (!) 3 lat: KLIK], albo pobawić się w analizę systemu z debuggerem podłączonym via local kernel debug i przejrzenie aktywnych pakietów irp oraz urządzeń i sterowników (tu za wiele nie pisałem, ale może coś pomoże: [KLIK]). Tak czy owak taka analiza wymaga czasu i pewnego doświadczenia przy takich zabawach, więc sugerowałbym najpierw podstawy - przejrzenie listy sterowników, eliminację podejrzanych, sprawdzenie co się dzieje na call stacku w procmonie przy starcie aplikacji, a dopiero potem zaglądanie głębiej. Można też zrobić full dump systemu [KLIK] i pobawić się offline'owo np. z użyciem Volatility, które wiele rzeczy upraszcza. m.g.

Tak.

Od paru dni przyglądam się tym wykresom, szukam jakiegoś punktu zaczepienia i drepczę w miejscu. Dlatego poproszę o wyłączenie Windows Defendera [KLIK], wyłączenie karty bezprzewodowej i przygotowanie jeszcze raz logu. m.g.

We wszystkich dumpach jest to samo - próba odwołania się do niedozwolonego adresu, wygląda jak błąd aplikacji, pamięci. Może być to problem jakiegoś AV / EMET, lub innego zabezpieczenia, a może faktycznie coś fizycznego - zaczął bym od usunięcia softu zabezpieczającego i jak to nie pomoże, to test pamięci. m.

Witam na forum. Dzięki za dumpy, jednak brakuje najważniejszego - zrzutu dla aplikacji, która się wykłada. A więc w momencie, gdy pojawia się tytułowy komunikat, poszukaj na liście procesów swojego Far Cry 3 i to temu procesowi zrób zrzut pamięci. Z tego co widzę, pozostałe aplikacje działają bez zarzutu. m.g.

Witam na forum, proszę nie dopisywać się do innych wątków - każdy temat to osobny przypadek. Z dumpa wynika, że prawdopodobnie problem dotyczy zewnętrznej (skopiowanej z Windows 8) biblioteki XINPUT9_1_0.dll, proszę zatem o zmianę nazwy pliku C:\WINDOWS\system32\XINPUT9_1_0.dll na C:\WINDOWS\system32\XINPUT9_1_0.old i ponowne uruchomienie programu. m.g.

1. Nie trzeba zamieniać dr Watsona; 2. Nie muszą, ale mogą, tak pewnie będzie wygodniej. W nazwie pliku zrzutu jest data i godzina, a w headerze dumpa informacja o poleceniu, więc bez problemu można się zorientować co i jak; 3. Dla wyjątków 1-ego rodzaju identycznie jak dla kolejnych - procdump po prostu będzie zbierał wcześniej zrzuty. m.

Ciężko wyczytać coś z tych dumpów, więc prośba o przygotowanie w nieco inny sposób - pod kontrolą procdump. W tym celu uruchom cmd.exe, przejdź do swojego katalogu z dumpami i dla każdego programu z osobna uruchom procdump w trybie oczekiwania: procdump.exe -e -ma -w "TorrentSpy-0.2.4.26.exe" po czym uruchom sam program (w tym przypadku jest to TorrentSpy-0.2.4.26.exe). Oczywiście dla innych programów zmień nazwę programu na odpowiednią (b2e.exe, Doctor.TCP.exe, etc.) Możesz także 'zasadzić się' na wyjątki pierwszego rodzaju, zmieniając nieco polecenie: procdump.exe -e 1 -ma -w "TorrentSpy-0.2.4.26.exe" Linki do dumpów poproszę tak jak poprzednio. m.g.