SOLUÇÃO: Foram as configurações de RAM o tempo todo :-| Nunca me ocorreu que as configurações de estoque em uma placa padrão com RAM padrão estariam tão distantes a ponto de causar instabilidade no sistema. Nunca fiz overclock, então nunca olhei atentamente para essas configurações. Depois que escolhi o perfil DOCP que correspondia à minha RAM, tudo ficou claro e ficou ainda um pouco mais rápido. Obrigado ao Twisty Impersonator pelo guia do processo e ao magicandre1981 pela sugestão que me levou a verificar as configurações. Esperançosamente, isso poupará 2 anos de frustração para outra pessoa.
EDIT: Bem, acho que a causa ficou clara. Depois de substituir TODO o hardware, e AINDA ver um problema, decidi voltar à ideia do hardware. Resumindo: se eu rodar com duas unidades de RAM, está tudo bem. Não importa quais são os dois palitos. Se eu colocar todos os quatro, começo a ter problemas. Esta parece ser uma indicação bastante clara de uma placa-mãe com defeito.
Os sintomas:
Nos últimos anos, minha máquina tem estado geralmente instável, ligando e desligando. Normalmente se manifesta como BSODs com códigos de parada variados.
- Atualizar a RAM melhorou a estabilidade por um tempo.
- Atualizar a placa-mãe melhorou a estabilidade por um tempo.
- A substituição da
C:unidade melhorou a estabilidade por um tempo. - Ocasionalmente, foi necessário atualizar ou reinstalar o sistema operacional e geralmente melhora a estabilidade por um tempo.
Substituí literalmente todos os componentes funcionais do sistema, exceto a CPU e a unidade Blu-ray. Não descartei a CPU, mas ainda há uma vasta gama de “coisas” de software que também podem ser culpadas.
Todas as vezes, o problema voltou depois de alguns meses.
Mais recentemente, os sintomas mudaram ligeiramente. Estou aberto à possibilidade de que este seja um problema completamente não relacionado, mas parece demasiado semelhante aos problemas com os quais tenho lutado o tempo todo, para ser mera coincidência.
Algumas semanas reiniciei meu computador para atualizar e isso não aconteceu POST. Eu me preocupei com isso por um tempo (verificando conexões, MemOK!botão, desconectando, TPUligando/desligando, EPUligando/desligando, etc.) e consegui POST, mas o sistema operacional não carregava. Esqueci a apresentação exata dos sintomas, mas o IIRC simplesmente ficaria parado e girando.
Reinstalei o sistema operacional e tudo ficou quieto por mais ou menos uma semana, até que os aplicativos começaram a travar. A princípio, parecia que todos os aplicativos que estavam travando estavam instalados no mesmo SSD. Sem espaço para movimentar as coisas e testar, atualizei para as novas unidades Samsung. Mas os aplicativos ainda estão travando.
- Atualização mais recente do BIOS. Nenhuma mudança.
- Acontece que você precisa redefinir o CMOS ao atualizar o BIOS. Os sintomas potenciais são muito parecidos com os meus. Eu reiniciei o CMOS. Nenhuma mudança.
- Geralmente eram os aplicativos de alta demanda que travavam (Dishonored 2, Diablo III, ESO, etc). Mas travamentos estão acontecendo entre 35°C e 45°C para CPU e GPU – então provavelmente não é temperatura.
- Não está ficando sem RAM.
MemTestnunca apresentou problemas. Já o executei dezenas de vezes.- Nenhum teste de CPU mostrou problemas, exceto em altas temperaturas.
- Nenhum teste de GPU mostrou problemas, exceto em altas temperaturas.
- Já reinstalei meus drivers de vídeo algumas dezenas de vezes.
- O Gerenciador de Tarefas travou enquanto assistia ontem.
- Tentei instalar um aplicativo da Windows Store. Algum processo em segundo plano travou. Tive que tentar novamente. Funcionou bem.
- Visualizador de eventos tem apenas
AppCrasheventos
AppCrasheventos estão sendo produzidos por uma ampla gama de aplicações. Variando tamanhos, locais, demandas, etc. Normalmente é uma vez por dia, talvez menos. Mas aplicativos com muitos recursos travam de maneira bastante confiável em cerca de 30 minutos.
Devo esclarecer que estes não são Windows is looking for a solutioneventos AppHang. O aplicativo simplesmente desaparece, como se eu o tivesse fechado, e o Windows não tem nada a dizer sobre isso, exceto o evento AppCrash no Visualizador de Eventos. Com menos frequência, há um BSOD. Ultimamente tenho visto IRQ not less than or equal, e outros que não consigo lembrar... (não tenho mais nenhum despejo de memória? Isso é estranho...).
Especificações do sistema:
- SO:Windows 10 Pro (atualizado do Win7 durante o período de atualização gratuita)
- CPU:AMD Phenom II 1090 (sem overclock)
- Resfriamento:Ventiladores de CPU CoolerMaster 150 mm, vários ventiladores de gabinete
- Placa-mãe:ASUS M4A99X EVO R2.0
- BATER:G.Skill 16 GB (4x4) DDR3-1333
- GPU:MSI GTX 970 (sem overclock)
- fonte de alimentação:Corsário CX750M
- Unidade do sistema:Samsung 850 EVO 500GB
- Outras unidades:Samsung 850 EVO 500GB, outras unidades convencionais, unidade óptica
- AV/V:Windows Defender, nenhum outro AV
Despejo de memória:
Solicitado por esta postagem:https://superuser.com/questions/1281659/possible-to-determine- which-core-a-faulting-application-was-on-when-it-crashed
Acerte um novo BSOD enquanto estava inativo na noite passada. Detalhes WhoCrashedabaixo:
Crash dump directory: C:\WINDOWS\Minidump
Crash dumps are enabled on your computer.
On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\Minidump\010318-12546-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1640E0)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows®
Operating System company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem. The crash took place in the Windows
kernel. Possibly this problem is caused by another driver that cannot be identified at this time.
On Wed 1/3/2018 9:00:13 AM GMT your computer crashed
crash dump file: C:\WINDOWS\memory.dmp
This was probably caused by the following module: ntdll.sys (ntdll!ZwFlushBuffersFile+0x14)
Bugcheck code: 0x1E (0xFFFFFFFFC0000005, 0xFFFFF8019CED183E, 0xFFFF968442FBEB68, 0xFFFF968442FBE3B0)
Error: KMODE_EXCEPTION_NOT_HANDLED
Bug check description: This indicates that a kernel-mode program generated an exception
which the error handler did not catch. This appears to be a typical software driver bug
and is not likely to be caused by a hardware problem. A third party driver was identified
as the probable root cause of this system error. It is suggested you look for an update for
the following driver: ntdll.sys.G
Google query: ntdll.sys KMODE_EXCEPTION_NOT_HANDLED
Despejos de memória (completos e mini) estarão aqui, conforme estiverem disponíveis:https://1drv.ms/f/s!AhSzRvnavkrXhPpNy8Qjhaj6LbbTwQ
@ magicandre1981 recomendado chkdsk /fcom base nos resultados do meu despejo de memória. C:é a única unidade para a qual um arquivo de paginação está habilitado (é gerenciado pelo sistema), então foi nessa unidade que eu executei. Aqui estão os resultados:
Verificando o sistema de arquivos em C: O tipo de sistema de arquivos é NTFS.
A disk check has been scheduled.
Windows will now check the disk.
Stage 1: Examining basic file system structure ...
605184 file records processed. File verification completed.
Deleting orphan file record segment 699DD.
10717 large file records processed. 0 bad file records processed.
Stage 2: Examining file name linkage ...
14846 reparse records processed. 704776 index entries processed. Index verification completed.
0 unindexed files scanned. 0 unindexed files recovered to lost and found. 14846 reparse records processed.
Stage 3: Examining security descriptors ...
Cleaning up 1426 unused index entries from index $SII of file 0x9.
Cleaning up 1426 unused index entries from index $SDH of file 0x9.
Cleaning up 1426 unused security descriptors.
Security descriptor verification completed.
49797 data files processed. CHKDSK is verifying Usn Journal...
37651904 USN bytes processed. Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.
No further action is required.
487284001 KB total disk space.
209659436 KB in 259738 files.
162276 KB in 49798 indexes.
0 KB in bad sectors.
729085 KB in use by the system.
65536 KB occupied by the log file.
276733204 KB available on disk.
4096 bytes in each allocation unit.
121821000 total allocation units on disk.
69183301 allocation units available on disk.
Internal Info:
00 3c 09 00 f0 b8 04 00 7e 93 08 00 00 00 00 00 .<......~.......
98 05 00 00 66 34 00 00 00 00 00 00 00 00 00 00 ....f4..........
Windows has finished checking your disk.
Please wait while your computer restarts.
Sem sorte. Mesmo depois que o chkdsk corrigiu esses problemas, ainda estou tendo as mesmas falhas, embora ainda não haja novos BSODs.
Outro BSOD quando abri o navegador para atualizar esta questão. Memdumps disponíveis assim que o upload for concluído.
Mas o motivo original pelo qual atualizei é que encontrei uma grande quantidade (51 para ser mais preciso) de eventos que parecem exatamente iguais. Parece que aconteciam a cada meia hora, começando logo depois que saí para o trabalho (7h30) até cerca de 20h30. Eles ainda podem estar acontecendo. Todos eles se parecemexatamenteesse:
Fault bucket 0x1E_c0000005_fltmgr!FltpPreFsFilterOperation, type 0
Event Name: BlueScreen
Response: Not available
Cab Id: 0
Problem signature:
P1: 1e
P2: ffffffffc0000005
P3: fffff8019ced183e
P4: ffff968442fbeb68
P5: ffff968442fbe3b0
P6: 10_0_16299
P7: 0_0
P8: 256_1
P9:
P10:
Attached files:
\\?\C:\WINDOWS\Minidump\010318-12546-01.dmp
\\?\C:\WINDOWS\TEMP\WER-18531-0.sysdata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5795.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57A5.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER57B6.tmp.txt
\\?\C:\Windows\Temp\WER8F12.tmp.WERDataCollectionStatus.txt
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Kernel_1e_b49232881f44bde28acca17f0ad8bac3b4fbb67_00000000_cab_031c57c4
Analysis symbol:
Rechecking for solution: 0
Report Id: 3c2abe43-d7d6-4561-9b0d-2adf1f40c745
Report Status: 388
Hashed bucket:
Tenho dificuldade em acreditar que a CPU teria esse problema por tanto tempo e o computador ainda funcionaria. Não tive muito sucesso explorando problemas de software/configuração.
Alguma ideia?
Quase 3 semanas depois.... Depois de MUITAS travessuras, finalmente adquiri um novo CPU (atualizado do Phenom II para o FX-8350). A substituição foi bastante fácil. Em seguida, investigue as áreas problemáticas comuns e os aplicativos ainda travarão.
Assim que postei “cara triste”, o Windows me contou algo sobre um “Relatório de integridade do dispositivo”. Ele relata problemas com um driver. Infelizmente, mas sem surpresa, o solucionador de problemas não conseguiu detectar nenhum tipo de problema. Desinstalei os dois dispositivos "USB Root Hub" em estado de erro do Gerenciador de dispositivos.
Isso fornece alguma pista adicional? Estou realmente perdido, agora...
Aqui está uma lista de informações do driver...? https://docs.google.com/spreadsheets/d/1xAliAOt1s8rQ_ePX5OwTRVFPB3kFYgc3-1HRUznMpR0/edit?usp=sharing
Responder1
Dividir e conquistar
Primeiro, você deve tentar determinar se isso é um problema de hardware ou software. Às vezes envolve ambos, mas inicialmente é melhor presumir que não.
Na minha experiência, a maneira mais eficaz de determinar qual campo está com defeito é inicializar em um segundo sistema operacional completamente diferente (sem alterar nenhum hardware, lembre-se) e tentar reproduzir o problema. É melhor usar um sistema operacional que não usequalquerdo mesmo código do sistema operacional suspeito. Por exemplo, se o seu sistema suspeito executa o Windows, você pode usar o Ubuntu como sistema operacional de teste. CDs ao vivo são bons para isso.
Com problemas que ocorrem intermitentemente, isso pode ser um desafio, mas seja como for, você precisa saber se:
- Ambos os sistemas operacionais são afetados, o que significa que você tem um problema de hardware ou
Apenas o seu sistema operacional suspeito é afetado, o que significa que você pode ter:
- Um problema de software ou
- Uma incompatibilidade entre um componente de hardware e um software específico (que quase sempre é um driver de terceiros).
Se você acha que é hardware
Você já testou e substituiu muitos componentes. Se o comportamento indesejado se manifestar em seu sistema operacional de teste, você estará munido de evidências conclusivas de que algo que você ainda não substituiu é o culpado. Para aqueles componentes que não se prestam a testes abrangentes (por exemplo, a placa-mãe), você provavelmente desejará tentar substituir primeiro outros componentes mais baratos, mas eventualmente você não terá escolha a não ser trocar também os componentes mais caros.
Se você acha que é software
Se o sistema operacional de teste não acionar a falha, você poderá ter mais certeza de que há um problema com o software no sistema operacional de destino. No entanto, se a falha historicamente não puder ser produzida sob demanda ou ocorrer apenas de forma intermitente, ainda há uma chance de que ainda seja um problema de hardware que simplesmente não foi acionado no sistema operacional de teste. Não pense nisso; apenas tenha isso em mente ao testar suas soluções provisórias.
Ao resolver qual código está com defeito, você obviamente deseja acompanhar mensagens de erro específicas, como códigos de verificação de bugs do Windows, erros registrados nos logs de eventos ou em logs específicos do aplicativo. Pularei essas etapas com base na suposição de que você esgotou esses leads e precisa de uma abordagem mais geral.
Quando não está claro qual software está com defeito, sua arma preferida éremova o software da equaçãoe execute o sistema por tempo suficiente para dar ao problema uma chance de ocorrer, se for o caso. Você pode fazer isso:
- Desinstale o software.
- Desative-o usando uma ferramenta como o Microsoft AutoRuns.
- Desative-o inicializando no modo de segurança.
- Crie uma segunda instalação do Windowssemo software em questão (útil se você realmente precisa do software para uso diário e deseja alternar facilmente entre o modo "teste" e "produção").
Ao fazer isso, gosto de categorizar o software do sistema da seguinte maneira e solucionar problemas de acordo:
- Código próprio do Windows e drivers de caixa de entrada.Menos provável que seja o culpado. Facilmente confirmado testando o sistema usando uma instalação original (uma semqualquercódigo de terceiros).
- Drivers de terceiros.Sempre causando problemas. Geralmente travam de maneira não aleatória, de modo que surge um padrão. Teste usando diferentes versões de driver ou trocando componentes de hardware.
- Software de nível de sistema de terceiros(por exemplo, software de segurança). Problemático. Eles raramente são necessários para o funcionamento adequado do sistema e podem ser completamente desinstalados para testar sua influência.
- Aplicativos de usuário.Comportamento de travamento altamente variável. Nas versões modernas do Windows, eles raramente travam ou travam todo o sistema. As falhas ocorrem apenas quando o aplicativo está em execução, por isso é fácil rastrear falhas e correlacioná-las com programas que estavam em execução no momento. Cuidado com os aplicativos de usuário que possuem um componente sempre ativo, como itens de inicialização ou serviços de sistema.
Mantenha um registro de trabalho semi-detalhado
Pensamento final aqui. Mantenha um registro das perguntas que você encontra e das etapas de solução de problemas que você executa. Com um problema difícil e extenso como este, é fácil esquecer os detalhes. Ser capaz de revisar isso enquanto você trabalha pode ajudá-lo a descartar causas ou a fazer conexões entre fatos que de outra forma poderiam se perder na luta.
História anedótica
Trabalhei em um sistema que me lembra sua situação. Era um laptop (que limitava minhas opções de troca de hardware) que travava aleatoriamente. Ele faria isso 10 segundos após ligar, depois não por dias e depois de ficar ligado por horas. Atualizei tudo, testei e substituí todos os componentes de hardware que pude e reinstalei o Windows (pelo menos uma vez, senão duas).
Acabou sendo a placa-mãe. Depois de substituído, o laptop funcionou por muitos anos sem maiores problemas.