Odkąd zacząłem używać systemu Windows 7, ten problem mnie niepokoi. Od czasu do czasu na różnych forach pojawiają się podobne pytania, ale nigdy nie widziałem odpowiedzi. Oto dwa scenariusze, które prawie zawsze go odtwarzają:
Droga odkrywcy
- W Eksploratorze przejdź do katalogu zawierającego co najmniej jeden plik exe
- Natychmiast przejdź o jeden katalog w górę
- Usuń katalog, do którego właśnie nawigowałem
- Uzyskuje dostęp do folderu Odmowa dostępu okno dialogowe informujące, że musisz wykonać pozwolenie, aby wykonać tę czynność Aby dokonać zmian w tym folderze , potrzebujesz pozwolenia od Administratora , za pomocą przycisków spróbuj ponownie i Anuluj
- Uderzenie Spróbuj ponownie nigdy nie działa natychmiast. Poczekanie około minuty, a następnie ponowne kliknięcie działa
Uwaga: jeśli w kroku 2 i odczekaniu minuty lub więcej przed przejściem do jednego katalogu problem nie wystąpi i folder można usunąć
Sposób Visual Studio
- Zbuduj projekt produkujący plik exe
- uruchom plik wykonywalny, a następnie zamknij go
- Natychmiast zbuduj projekt ponownie (na przykład zmieniając pojedynczy znak w pliku źródłowym)
- Daje błąd krytyczny LNK1168: nie można otworzyć /path/to/the.exe do pisania
Uwaga: jeśli w kroku 2 i odczekaniu minuty lub więcej przed ponownym zbudowaniem, problem nie występuje.
Niektóre specyfikacje
- Zdarza się zarówno w systemie Windows 7 32-bitowym, jak i 64-bitowym, z VS2008 / 2010/2011
- Zdarza się na 3 różnych maszynach
- Nie mam żadnego skanera antywirusowego
- Mam kilka usług wyłączonych, ale nic, co nie uniemożliwia normalnego działania systemu Windows, UAC jest również wyłączone
- Zdarza się na każdym rodzaju dysku
- Zawsze używam konta użytkownika należącego do grupy Administratorzy
Oczywiście oba scenariusze są bardzo podobne i niezwykle powtarzalne. Pomyślałem, że jakiś proces musi z jakiegoś powodu otworzyć plik i zwolnić go później. Jednak za pomocą sysinternals
handle -a
plik exe, o którym mowa, nigdy się nie pojawia. (to jest właściwy sposób korzystania z uchwytu, prawda?) Więc podczas gdy explorer / VS zgłaszają, że nie mogą uzyskać dostępu do pliku, handle.exe twierdzi, że nigdzie nie jest używany. Pozostaje mi to raczej nieświadomy, więc zastanawiam się, czy ktoś może wymyślić rozwiązanie: dlaczego tak się dzieje i jak to rozwiązać?
Zaktualizuj w odpowiedzi na zadane pytania:
- Nie można odtworzyć problemu w trybie awaryjnym
- Zainstalowano kilka rozszerzeń powłoki. Od SellExView, oto nie-microsoftowe, które są wspólne dla wszystkich maszyn: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Uważam te Tortoise za najbardziej podejrzane, chociaż dla obu opcji „Status Cache” jest ustawiona na „Status Cache tylko dla jednego folderu, bez nakładek rekurencyjnych”, tzn. Nie ma uruchomionego TortoiseCache.exe.
- W przypadku problemu eksploratora ProcessExplorer nie pokazuje pliku wykonywalnego. Pokazuje jednak katalog pliku wykonywalnego, ale pokazuje go nawet po usunięciu, więc wydaje się, że nie jest tak naprawdę powiązany
- W przypadku problemu VS dzieje się tak w przypadku VS, nawet gdy okno eksploratora nie jest otwarte w katalogu docelowym. I znowu ProcessExplorer nie pokazuje pliku wykonywalnego ani katalogu, w którym znajduje się plik wykonywalny. Zauważ, że w tym „trybie” z VS problem występuje tylko podczas uruchamiania pliku wykonywalnego. Jeśli nie jest uruchomiony, mogę go budować bez problemu raz po raz.
- W „trybie VS” i otwartym oknie eksploratora w katalogu pliku wykonywalnego (testowane tylko w exe C #) robi się dziwniej: nie mogę budować ponownie, ponieważ VS narzeka, że exe jest używany przez inny proces. Jeśli jednak usunę exe z otwartego okna eksploratora, to zadziała, a w konsekwencji kompilacja się powiedzie. Ponownie, nie ma żadnych odniesień w ProcessExplorer. Co wydaje się pasować do moich ustaleń z uchwyt.exe (czy PE i uchwyt i tak nie używają tego samego API wewnętrznie?)
Aktualizacja 2 To nie może być zwykły odkrywca: po zabiciu explorer.exe problem VS nadal występuje.
Aktualizacja 3 Korzystanie z Monitora procesów, jak sugeruje Asher, ujawnia ciekawe fakty: w trybie eksploratora po otwarciu katalogu jest 10 wywołań IRP_MJ_CREATE. Jednak tylko 9 połączeń z IRP_MJ_CLEANUP. Wszystkie te wywołania pochodzą z powłoki shell32.dll, więc zdecydowanie nie jest to problem z instalacją innej firmy. I oczywiście ten brakujący IRP_MJ_CLEANUP powoduje problem: dokładnie 1 minutę po otwarciu katalogu sam proces systemowy wydaje wywołanie IRP_MJ_CLEANUP, a plik jest zwalniany i usuwany.
Nadal jednak nie mogłem zrozumieć, dlaczego tak się dzieje. Czy to błąd eksploratora wywołany przez jakąś zmianę, którą wprowadziłem?
Rozwiązanie! Przeglądając usługi, które wyłączyłem, zauważyłem opis aplikacji Application Experience i cytuję: Przetwarza żądania pamięci podręcznej zgodności aplikacji podczas ich uruchamiania . Brzmi znajomo. I rzeczywiście, po uruchomieniu usługi nie mogę już odtworzyć żadnego z problemów, a wydajność ProcMon jest inna i krótsza. Zabawne jednak, ponieważ po ponownym zatrzymaniu usługi wszystko jest nadal w porządku, a wydajność procmon jest jeszcze krótsza.
Próbowałem tego na dwóch komputerach, przy czym wszystkie rzeczy innych firm były z radością uruchomione i wszystko jest nadal w porządku.
Nie jestem pewien, czy to prawdziwy błąd (można by powiedzieć „czego można się spodziewać po wyłączeniu usług”), ale nie jest normalne, że problem zniknie po prostu poprzez uruchomienie usługi, a następnie zatrzymanie jej ponownie.
Bounty trafia do każdego, kto może zapewnić głębszy wgląd w to, a także do @Asher za skierowanie mnie do ProcMon, co ostatecznie poprowadziło mnie we właściwym kierunku.
źródło
Odpowiedzi:
Myślę, że problem, który widzisz, jest związany z thumbs.db, który tworzy Eksplorator Windows. Spróbuj to wyłączyć, uruchom ponownie i sprawdź, czy problem się powtarza.
Aby wyłączyć thumbs.db, otwórz edytor zasad grupy (gpedit.msc), przejdź do Konfiguracja użytkownika - Panel sterowania> Szablony administracyjne - Opcje folderów> Karta Składniki systemu Windows - karta Viev> Eksplorator Windows. znajdź „Wyłącz buforowanie miniatur w ukrytych plikach thumbs.db” i włącz opcję Nie buforuj miniatur.
Jeśli to nie zadziała, spróbuję to zbadać za pomocą Sysinternals Process Monitor. użyj go, aby obserwować, kto uzyskuje dostęp do folderu, gdy odmówisz dostępu. sprawdź, czy w rzeczywistości jest to odmowa dostępu lub naruszenie udostępniania, co oznacza, że ktoś trzyma plik.
źródło
%userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), chyba że zasób jest zdalny (jak w przypadku udziału sieciowego), w którym to momencie użyjethumbs.dbprzechowywanego w zdalnej lokalizacji (można to wyłączyć przez GP).Czy na pewno nie masz zainstalowanego żadnego produktu zabezpieczającego?
Opisane przez Ciebie scenariusze są zgodne z teorią, że jakiś produkt uzyskuje dostęp do każdego pliku wykonywalnego, do którego masz dostęp w jakikolwiek sposób, uniemożliwiając wyłączny dostęp do niego. Nie musi to być program antywirusowy, może to być na przykład indeksator do szybkiego wyszukiwania lub cokolwiek innego (nawet wirus).
Tę teorię można przetestować, uruchamiając komputer w trybie awaryjnym, w którym nie są uruchamiane żadne produkty oprócz systemu Windows.
Najlepszym narzędziem do śledzenia dostępu do plików jest Process Monitor . Kolejnym doskonałym narzędziem do znajdowania wszystkich produktów startowych oraz ich wyłączania i ponownego włączania jest Autoruns .
źródło
Plik lub katalog można następnie otworzyć w trybie jądra
nie pokaże go, a ProcMon wyświetli żądania IRP z / do procesu systemowego.
Część jądra systemu Windows jest odwzorowana na wszystkie procesy, a część jądra systemu Windows działa w osobnym procesie. Ten ostatni nazywa się Windows Executive.
Jest to spowodowane przez plik lub katalog otwarty z trybu jądra w procesie Windows Executive.
źródło
Może to być Eksplorator odczytujący ikony i metadane z pliku exe.
źródło