Desde que comecei a usar o Windows 7, esse problema está me incomodando. De tempos em tempos, vejo perguntas semelhantes surgindo em fóruns diversos, mas nunca vi uma resposta. Aqui estão dois cenários que quase sempre o reproduzem:
A maneira do explorador
- Com o explorer, navegue para um diretório que contém pelo menos um arquivo exe
- Suba um diretório imediatamente
- Exclua o diretório que acabou de navegar para
- Rende acesso negado à pasta, caixa de diálogo negada informando Você precisa de permissão para executar esta ação Você precisa de permissão dos Administradores para fazer alterações nesta pasta . Com os botões, tente Novamente e Cancelar
- Bater em Try Again nunca funciona imediatamente. Esperar mais ou menos um minuto e clicar novamente nele funciona
Nota: Se na etapa 2 e aguardar um minuto ou mais antes de subir em um diretório, o problema não ocorrerá e a pasta poderá ser excluída
A maneira do Visual Studio
- Construir um projeto produzindo um arquivo exe
- execute o executável e feche-o
- Crie imediatamente o projeto novamente (alterando um único caractere em um arquivo de origem, por exemplo)
- Rende erro fatal LNK1168: não é possível abrir /caminho/to/the.exe para gravação
Nota: Se na etapa 2 e aguardar um minuto ou mais antes de compilar novamente, o problema não ocorre.
Algumas especificações
- Acontece no Windows 7 de 32 e 64 bits, com o VS2008 / 2010/2011
- Acontece em 3 máquinas diferentes
- Não tenho antivírus de nenhum tipo
- Eu tenho vários serviços desabilitados, mas nada que impeça a execução normal do Windows, o UAC também é desabilitado
- Acontece em qualquer tipo de disco
- Eu sempre uso uma conta de usuário que está no grupo Administradores
Obviamente, ambos os cenários são muito semelhantes e extremamente reproduzíveis. Por isso, achei que algum processo deve ter o arquivo aberto por algum motivo e liberá-lo novamente mais tarde. No entanto, usando sysinternals
handle -a
o arquivo exe em questão nunca aparece. (essa é a maneira correta de usar o identificador, certo?) Portanto, enquanto o explorer / VS está relatando que não pode acessar o arquivo, o handle.exe diz que não está em uso em nenhum lugar. Isso me deixa um pouco sem noção, então estou me perguntando se alguém pode encontrar uma solução: por que isso acontece e como resolvê-lo?
Atualização em resposta às perguntas:
- Não consegui reproduzir o problema no modo de segurança
- Um monte de extensões de shell está instalado. No SellExView, aqui estão os que não são da Microsoft e são comuns a todas as máquinas: NitroPDF, WinRAR, TortoiseGit, TortoiseSvn, NVidia. Eu consideraria os Tortoise os mais suspeitos, embora para a opção 'Status Cache' seja definida como 'Status cache apenas para uma pasta, sem sobreposições recursivas', ou seja, não há TortoiseCache.exe em execução.
- Com o problema do explorador, o ProcessExplorer não mostra o executável. No entanto, ele mostra o diretório do executável, mas continua mostrando mesmo depois que foi excluído, o que não parece realmente relacionado
- Com o problema do VS, isso acontece com o VS, mesmo quando nenhuma janela do Explorer é aberta no diretório de destino. E, novamente, ProcessExplorer não mostra o executável, nem o diretório em que o executável está. Observe que nesse 'modo' com o VS, o problema ocorre apenas ao executar o executável. Se não estiver em execução, posso construí-lo sem problemas várias vezes.
- No 'modo VS' e uma janela do explorer aberta no diretório do executável (testada apenas com um exe em C #), fica mais estranho: não consigo criar novamente porque o VS reclama que o exe está sendo usado por outro processo. No entanto, se eu excluir o exe da janela aberta do explorer, isso funcionará e, consequentemente, a criação será bem-sucedida. Novamente, não há referências no ProcessExplorer. O que parece corresponder às minhas descobertas com handle.exe (o PE e o handle não usam a mesma API internamente?)
Atualização 2 Não pode ser apenas o explorer: depois de matar o explorer.exe, o problema do VS ainda está lá.
Atualização 3 O uso do Process Monitor como Asher sugere revela fatos interessantes: para o modo explorer, há 10 chamadas para IRP_MJ_CREATE ao abrir o diretório. No entanto, apenas 9 chamadas para IRP_MJ_CLEANUP. Todas essas chamadas são originárias do shell32.dll, portanto, definitivamente não é um problema de instalação de terceiros. E é obviamente o único IRP_MJ_CLEANUP ausente que causa o problema: exatamente 1 minuto após a abertura do diretório, o próprio processo do sistema emite a chamada IRP_MJ_CLEANUP e o arquivo é liberado e excluído.
No entanto, eu ainda não conseguia descobrir por que isso acontece. É um bug do explorer desencadeado por alguma alteração que fiz?
Solução! Examinando os serviços que desabilitei, observei a descrição do Application Experience e cito Processos de pedidos de cache de compatibilidade de aplicativos quando eles são iniciados . Soa familiar. E, de fato, depois de iniciar o serviço, não consigo mais reproduzir nenhum dos problemas e a saída do ProcMon é diferente e mais curta. Engraçado, porém, porque depois de interromper o serviço novamente, tudo continua bem e a saída do procmon ainda é mais curta.
Eu tentei isso em duas máquinas, com todas as coisas de terceiros em execução feliz e tudo ainda está bem.
Não tenho certeza se esse é um bug real (pode-se dizer 'o que você espera com a desativação de serviços'), mas não é exatamente normal que o problema desapareça simplesmente iniciando um serviço e parando-o novamente.
Bounty é direcionado a qualquer pessoa que possa fornecer uma visão mais profunda sobre isso, além de @Asher por me indicar o ProcMon, que acabou me levando na direção certa.