Akses Windows 7 ditolak untuk dieksekusi .. oleh apa?


14

Sejak saya mulai menggunakan Windows 7, masalah ini mengganggu saya. Dari waktu ke waktu saya melihat pertanyaan serupa bermunculan di forum misc, tetapi saya tidak pernah melihat jawaban. Berikut adalah dua skenario yang hampir selalu mereproduksinya:

Cara penjelajah

  1. Dengan explorer, navigasikan ke direktori yang berisi setidaknya satu file exe
  2. Buka satu direktori dengan segera
  3. Hapus direktori yang baru saja dinavigasi
  4. Dialog Akses Folder Yield Ditolak yang menyatakan Anda perlu izin untuk melakukan tindakan ini. Anda memerlukan izin dari Administrator untuk membuat perubahan pada folder ini , dengan tombol coba Lagi dan Batal
  5. Memukul Coba Lagi tidak pernah berfungsi dengan segera. Menunggu sekitar satu menit dan kemudian mengkliknya lagi tidak berfungsi

Catatan: Jika dalam langkah 2 dan menunggu satu menit atau lebih sebelum naik satu direktori, masalahnya tidak terjadi dan folder dapat dihapus

Cara Visual Studio

  1. Bangun proyek yang menghasilkan file exe
  2. jalankan executable lalu tutup
  3. Segera buat proyek lagi (dengan mengubah satu karakter dalam file sumber misalnya)
  4. Menghasilkan kesalahan fatal LNK1168: tidak dapat membuka /path/to/the.exe untuk menulis

Catatan: Jika dalam langkah 2 dan menunggu satu menit atau lebih sebelum membangun lagi, masalahnya tidak terjadi.

Beberapa spesifikasi

  • Terjadi pada Windows 7 32 dan 64 bit, dengan VS2008 / 2010/2011
  • Terjadi pada 3 mesin yang berbeda
  • Saya tidak memiliki pemindai virus dalam bentuk apa pun
  • Saya memang memiliki banyak layanan yang dinonaktifkan, tetapi tidak ada yang mencegah Windows berjalan normal, UAC juga dinonaktifkan
  • Terjadi pada semua jenis disk
  • Saya selalu menggunakan akun pengguna yang ada di grup Administrator

Jelas kedua skenario sangat mirip dan sangat bisa direproduksi. Jadi saya pikir beberapa proses harus memiliki file terbuka karena suatu alasan, dan lepaskan lagi nanti. Namun, menggunakan sysinternals

handle -a

file exe yang dipermasalahkan tidak pernah muncul. (itu adalah cara yang benar untuk menggunakan pegangan, kan?) Jadi sementara explorer / VS melaporkan mereka tidak dapat mengakses file, handle.exe mengatakan itu tidak digunakan di mana pun. Ini membuat saya agak tidak mengerti, jadi saya bertanya-tanya apakah seseorang dapat menemukan solusi: mengapa ini terjadi, dan bagaimana mengatasinya?

Pembaruan dalam menanggapi pertanyaan yang diajukan:

  • Saya tidak dapat mereproduksi masalah dalam Safe Mode
  • Sekelompok ekstensi shell diinstal. Dari SellExView, berikut ini adalah non-microsoft yang umum untuk semua mesin: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Saya akan menemukan Tortoise yang paling mencurigakan, meskipun untuk kedua opsi 'Status Cache' diatur ke 'Cache status hanya untuk satu folder, tidak ada overlay rekursif' yaitu tidak ada TortoiseCache.exe berjalan.
  • Dengan masalah explorer, ProcessExplorer tidak menunjukkan executable. Itu memang menunjukkan direktori yang dapat dieksekusi, tetapi terus menunjukkan bahkan setelah itu dihapus sehingga tampaknya tidak benar-benar terkait
  • Dengan masalah VS, itu terjadi dengan VS bahkan ketika tidak ada jendela explorer terbuka di direktori target. Dan lagi, ProcessExplorer tidak menunjukkan executable, atau direktori executable masuk. Perhatikan bahwa dalam 'mode' ini dengan VS, masalah hanya terjadi ketika menjalankan executable. Jika tidak menjalankannya, saya dapat membangunnya tanpa masalah dari waktu ke waktu.
  • Dalam 'VS mode' dan jendela explorer terbuka pada direktori yang dapat dieksekusi (hanya diuji dengan C # exe), akan lebih aneh: Saya tidak dapat membangun lagi karena VS mengeluh bahwa exe sedang digunakan oleh proses lain. Namun, jika saya menghapus exe dari jendela explorer terbuka, ini berfungsi, dan akibatnya membangun berhasil. Sekali lagi, tidak ada referensi di ProcessExplorer sama sekali. Yang sepertinya cocok dengan temuan saya dengan handle.exe (bukankah PE dan handle menggunakan API yang sama secara internal?)

Pembaruan 2 Tidak bisa hanya explorer: setelah membunuh explorer.exe, masalah VS masih ada.

Pembaruan 3 Menggunakan Monitor Proses sebagaimana disarankan Asher mengungkapkan fakta menarik: untuk mode penjelajah, ada 10 panggilan ke IRP_MJ_CREATE saat membuka direktori. Namun hanya 9 panggilan ke IRP_MJ_CLEANUP. Semua panggilan ini berasal dari dalam shell32.dll, jadi sudah pasti bukan masalah pemasangan pihak ke-3. Dan itu jelas merupakan IRP_MJ_CLEANUP yang hilang yang menyebabkan masalah: tepat 1 menit setelah membuka direktori, proses Sistem itu sendiri mengeluarkan panggilan IRP_MJ_CLEANUP dan file dilepaskan, dan dihapus.

Namun, saya masih tidak tahu mengapa ini terjadi. Apakah itu bug penjelajah yang dipicu oleh beberapa perubahan yang saya buat?

Larutan! Melihat melalui layanan yang telah saya nonaktifkan, saya perhatikan deskripsi untuk Pengalaman Aplikasi mengatakan, dan saya kutip, Memproses permintaan cache kompatibilitas aplikasi untuk aplikasi saat diluncurkan . Kedengarannya familiar. Dan memang, setelah memulai layanan saya tidak dapat mereproduksi masalah lagi dan hasil ProcMon berbeda dan lebih pendek. Lucu juga, karena setelah menghentikan layanan lagi, semuanya masih baik-baik saja dan output procmon masih lebih pendek.

Saya mencoba ini pada dua mesin, dengan semua hal pihak ke-3 berjalan dengan gembira dan semuanya masih baik-baik saja.

Saya tidak yakin apakah ini bug nyata (bisa dikatakan 'apa yang Anda harapkan dengan menonaktifkan layanan'), tetapi tidak sepenuhnya normal bahwa masalahnya hilang hanya dengan memulai layanan dan kemudian menghentikannya lagi.


Bounty pergi ke siapa saja yang dapat memberikan wawasan yang lebih dalam tentang hal ini, atau kepada @ Asher karena mengarahkan saya ke ProcMon yang pada akhirnya membawa saya ke arah yang benar.


2
Beberapa pertanyaan. Apakah masalah penjelajah terjadi dalam mode aman? Apakah Anda memiliki ekstensi shell yang diinstal? Dengan masalah Visual studio Anda, jika Anda menjalankan proses monitor dan memfilter ke exe Anda apakah itu menunjukkan sesuatu mengakses file?
sgmoore

Aneh, kedua skenario yang Anda sarankan berfungsi seperti yang diharapkan untuk saya (tidak ada kesalahan). Seperti yang disarankan sgmoore, keluarkan Process Monitor dan monitor folder / file.
Ƭᴇcʜιᴇ007

@sgmoore lihat pembaruan
stijn

Apakah Anda 100% yakin bahwa hanya karena panggilan berasal dari shell32.dll maka aturan ini tidak diinstal pihak ketiga? Saya tidak cukup tahu tentang apa yang terjadi pada tingkat yang sangat rendah untuk memastikan apakah itu benar atau tidak, tetapi tentu saja itu bukan asumsi yang akan saya buat.
sgmoore

@sgmoore 100% tidak, tapi 99%, ya. Kesimpulan saya tidak hanya berdasarkan pada apa yang saya tulis di sini; Saya memiliki simbol untuk semua sistem dll, jadi saya melihat nama fungsi lengkap di callstack procmon. Semua panggilan yang dibuat oleh explorer ketika membuka direktori berasal dari kelas dengan nama seperti CLoadIconTask, nama yang telah menuliskan 'Microsoft' di atasnya. Saya seorang programmer jadi saya memiliki pengetahuan tentang menafsirkan callstacks. Semuanya non-microsoft masih dinonaktifkan di AutoRuns. Di komputer lain tidak, namun seluruh output procmon sama. Semua intuisi ini membuat saya sangat percaya hanya MS.
stijn

Jawaban:


7

Saya pikir masalah yang Anda lihat terkait dengan thumbs.db yang dibuat Windows explorer. Coba nonaktifkan ini, reboot dan lihat apakah masalahnya terjadi kembali.

Untuk menonaktifkan thumbs.db, buka editor Kebijakan Grup (gpedit.msc), buka Konfigurasi Pengguna-Panel Kontrol> Administratif Templat-Folder Pilihan> tab Windows Components-Viev> Windows Explorer. temukan "Matikan caching thumbnail di file thumbs.db tersembunyi" dan aktifkan ituTidak Cache Thumbnail.

Jika tidak berhasil saya akan mencoba menyelidikinya menggunakan Sysinternals Process Monitor. menggunakannya untuk menonton siapa yang mengakses folder ketika Anda mendapat akses ditolak. lihat apakah itu sebenarnya merupakan akses yang ditolak atau pelanggaran berbagi yang berarti seseorang memegang file tersebut.


1
Thumbs.db tidak ada di win7.
kinokijuf

1
ya benar. buka Opsi Folder dan aktifkan "tampilkan file, folder, dan drive"
Asher

1
Windows 7 menggunakan cache thumbnail lokal ( %userprofile%\AppData\Local\Microsoft\Windows\Explorer\thumbcache_*.db), kecuali jika sumber dayanya jauh (seperti pada jaringan berbagi) pada titik mana ia akan menggunakan yang thumbs.dbtersimpan di lokasi jarak jauh (ini dapat dinonaktifkan oleh GP).
Ƭᴇcʜιᴇ007

2
upvoted: walaupun saya tidak memiliki opsi Thumbnail Do Not Cache, menggunakan ProcMon akhirnya membawa saya ke suatu tempat, karena memberikan bukti masalah, tidak seperti ProcessExplorer atau handle: tepat 1 menit setelah membuka direktori atau menjalankan exe, ada IRP_MJ_CLEANUP operasi dari proses Sistem yang tampaknya melepaskan file: tepat setelah peristiwa itu saya dapat menghapus direktori lagi. Saya akan menyelidiki hal ini lebih lanjut, jika saya bisa memahami apa yang disediakan ProcMon.
stijn

3
@kinokijuf Saya baru saja memperhatikan Anda telah mengacaukan jawaban Ahser. Saya tidak tahu mengapa Anda melakukannya, tetapi itu tidak masuk akal: pertama Anda mengatakan, dengan berani, bahwa tidak ada thumbs. Kemudian Anda mengedit jawaban Asher sehingga bagian di mana ia mengatakan cara menonaktifkan thums.db, membuatnya tidak dapat digunakan ("Do Not Cache Thumnbnails" adalah untuk XP). Tolong jangan lakukan hal seperti itu.
stijn

3

Anda yakin tidak memasang produk keamanan apa pun?

Skenario yang Anda jelaskan kompatibel dengan teori bahwa beberapa produk mengakses setiap file yang dapat dieksekusi yang diakses oleh Anda dengan cara apa pun yang memungkinkan, sehingga membuat akses eksklusif ke sana menjadi tidak mungkin. Ini tidak harus menjadi antivirus, bisa jadi misalnya pengindeks untuk pencarian cepat atau apa pun (bahkan virus).

Seseorang dapat menguji teori ini dengan mem-boot dalam mode Aman di mana tidak ada produk kecuali untuk Windows yang diluncurkan sama sekali.

Alat terbaik untuk melacak akses file adalah Process Monitor . Alat luar biasa lainnya untuk menemukan semua produk startup dan mematikannya lagi adalah Autoruns .


pengindeksan adalah, pencarian windows tidak aktif juga. Saya tidak memiliki alat keamanan atau alat pencarian pihak ketiga dalam bentuk apa pun; pada dasarnya saran Anda adalah menonaktifkan alat pihak ke-3 di autoruns, lalu aktifkan satu per satu?
stijn

Jika ini tidak terjadi dalam mode boot Aman, maka itu benar-benar yakin bahwa beberapa produk yang diinstal bertanggung jawab. Anda bisa menggunakan Autoruns untuk menonaktifkan item startup dalam batch dan reboot, sampai Anda menemukannya. Keuntungan dari Autoruns adalah Anda dapat dengan mudah mengaktifkan kembali item, serta menyimpan / mengembalikan / membandingkan situasi saat ini. Tetapi lebih baik lagi membuat titik pemulihan sistem, untuk berjaga-jaga.
harrymc

menonaktifkan semua non-microsoft di bawah Logon, Explorer, Internet Explorer, dan layanan. Masalah masih ada. Apakah ada cara untuk membandingkan apa yang dimuat dalam mode normal vs dalam mode aman?
stijn

Pada dasarnya, semua yang Anda lihat di Autoruns hanya dimuat dalam mode normal.
harrymc

Nah, kecuali untuk Layanan, Jaringan dll.
harrymc

2

File atau direktori dapat dibuka dari mode kernel, lalu

handle -a

tidak akan menampilkannya dan ProcMon akan menampilkan permintaan IRP dari / ke proses Sistem.

Ada bagian dari Kernel Windows yang dipetakan ke semua proses dan ada bagian lain dari Kernel Windows yang berjalan dalam proses terpisah. Yang terakhir disebut Windows Executive.

Jadi ini disebabkan oleh file atau direktori dibuka dari mode kernel dalam proses Windows Executive.


1

Mungkin Explorer membaca ikon dan metadata dari exe.


Ini adalah penjelasan yang mungkin untuk Explorer, tetapi tidak untuk studio visual kecuali jika Explorer menampilkan folder ini pada saat yang bersamaan. @stijn: Apakah ini terjadi di studio visual tanpa Explorer?
harrymc

@harrymc lihat pembaruan, tidak terjadi tanpa explorer (yah, explorer.exe masih berjalan, tetapi tidak ada di direktori exe)
stijn

Dan bagaimana cara mengatasi masalah ini?
Simon Sheehan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.