Follow along with the video below to see how to install our site as a web app on your home screen.
Observação: This feature currently requires accessing the site using the built-in Safari browser.
Prezados usuários,
Por questões de segurança, a partir de 22/04/2024 os usuários só conseguirão logar no fórum se estiverem com a "Verificação em duas etapas" habilitada em seu perfil.
Para habilitar a "Verificação em duas etapas" entre em sua conta e "Click" em seu nick name na parte superior da página, aparecerá opções de gestão de sua conta, entre em "Senha e segurança", a primeira opção será para habilitar a "Verificação em duas etapas".
Clicando alí vai pedir a sua senha de acesso ao fórum, e depois vai para as opções de verificação, que serão as seguintes:
***Código de verificação via aplicativo***
>>>Isso permite que você gere um código de verificação usando um aplicativo em seu telefone.
***Email de confirmação***
>>>Isso enviará um código por e-mail para verificar seu login.
***Códigos alternativos***
>>>Esses códigos podem ser usados para fazer login se você não tiver acesso a outros métodos de verificação.
Existe as 3 opções acima, e para continuar acessando o fórum a partir de 22/04/2024 você deverá habilitar uma das 03 opções.
Bom galera, toda pessoa que faz overclock se depara sempre com alguma BSOD até acertar seu overclock e essas BSOD's por íncrivel que pareça podem ajudar a identificar o erro e qual voltagem está faltando ou em excesso.
Navegando na net achei isso e resolvi compartilhar com vocês !!!
Aqui está uma SS com o erro no código 0x101, possívelmente falta de Vcore.
:fuuu:
0x101 = Aumentar Vcore 0x124 = Aumentar ou reduzir QPI/VTT, pode ser o Vcore também 0x0A = RAM/IMC instáveis , primeiro aumentar o VTT 0x1A = Erro de gerenciamento de memória. Pode significar um pente de RAM com defeito, para sanar as dúvidas rode o memtest. E tente aumentar a voltagem da RAM.(1.5V~1.65V) 0x1E = Aumentar Vcore 0x3B = Aumentar Vcore 0x3D = Aumentar Vcore 0xD1 = QPI/VTT, aumentar, reduzir se necessário 0x9C = QPI/VTT maioria das vezes, mas aumentando o Vcore pode ajudar também 0x50 = Ram/ Latência / Uncore multiplicador , aumentar voltagem da memória ou QPI/VTT, ou reduzir o Uncore ( 1366 ) caso ele esteja maior que 2x. 0x109 = Muita ou pouca voltagem na memória 0x116 = Voltagem do IOH (NB) baixa, Problema na VGA (mais comum usando SLI/ Crossfire ou VGA overclockada ) 0x7E = Arquivos do S.O. corrompidos, possivelmente pelo erro no overclock . Executar chkdsk /r
BSOD Codes for SandyBridge
0x124 = add/remove vcore or QPI/VTT voltage (usually Vcore, once it was QPI/VTT) 0x101 = add more vcore 0x50 = RAM timings/Frequency add DDR3 voltage or add QPI/VTT 0x1E = add more vcore 0x3B = add more vcore 0xD1 = add QPI/VTT voltage 0x9C = QPI/VTT most likely, but increasing vcore has helped in some instances” 0X109 = add DDR3 voltage 0x0A = add QPI/VTT voltage
Outra coisa :
Por padrão no Windows 7, quando você receber uma tela azul da morte (BSOD) sua máquina irá reiniciar automaticamente. As vezes isso pode ser ruim posi não dá pra vermos qual o erro apresentado. Aqui está como desativar a reinicialização automática do Windows 7.
1) Vá ao painel de controle.
2) Vá em Sistema e Segurança e, em seguida, clique no link do Sistema.
3) No lado esquerdo da janela, clique no link Configurações Avançadas do Sistema.
4) Clique na aba Avançado.
5) Na seção Inicialização e recuperação, clique no botão Configurações ....
6) Na seção de falha do sistema, desmarque a opção para reiniciar automaticamente.
7) Clique em OK para salvar suas alterações.
Fazendo isso o sistema ficará parado na tela azul e só apertando o reset ele reiniciará !!!
Ótimo post Bruno! Realmente foi muito bom você reunir todos os códigos de erro das BSOD’s neste tópico, já havia anotado alguns códigos postados pelo Cata em algum tópico sobre overclock.
Porém, gostaria de complementar este post, se possível adicionar até a página principal, porque condiz com o título do tópico.
Bem provável que alguém já ouviu falar que após algumas tentativas de overclock e várias BSOD’s, mesmo incrementando voltagens e outros ajustes finos, não conseguiram estabilidade. Quando colocaram o sistema em “stock”, as BSOD’s continuaram. E agora como descobrir o real motivo destes “crashes”?
Simples, basta analisar o “mini-dump” gerador pelo “crash”.
Antes de apresentar o tutorial de como analisar estes arquivos, gostaria de complementar que geralmente quando as BSOD’s continuam com o sistema em “stock”, é porque durante as tentativas de overclock, talvez algum driver do S.O. (Sistema Operacional) foi atualizado automaticamente ou algum hardware novo adicionado e não nos demos conta disso. Já verifiquei casos em que um simples Modem 3G ou um mouse diferente começou a causar as famigeradas telas azuis. Outro fator que podemos levar em conta, é que talvez algum arquivo do sistema está danificado e através do “mini-dump”, talvez seja possamos identificá-lo.
4) Agora clique novamente em “File” e depois em “Save Workspace”, assim não necessitamos configurar novamente esta pasta.
Agora que a fonte para os Symbols está devidamente configurada, já podemos analisar algum “mini-dump”.
1) Abra o WinDbg e clique em “File > Open Crash Dump”
Obs. Os arquivos gerados pelas telas azuis estão nesta pasta:
“C:\Windows\Minidump”
2) Após abrir o arquivo de dump, ele efetuará o download das Symbols necessárias para analisar o arquivo, este processo poderá demorar um pouco.
3) Então após ele ter carregado tudo, basta digitar na linha de comando da janela:
“!analyze –v”
Exemplo:
Código:
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Mini062908-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Sun Jun 29 11:06:27.767 2008 (GMT+1)
System Uptime: 7 days 1:18:54.062
Loading Kernel Symbols
.............................................................................................................
Loading User Symbols
Loading unloaded module list
........................
Unable to load image SYMTDI.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for SYMTDI.SYS
*** ERROR: Module load completed but symbols could not be loaded for SYMTDI.SYS
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000000A, {c0000000, 2, 0, 80505c1f}
*** WARNING: Unable to verify timestamp for Rtnicxp.sys
*** ERROR: Module load completed but symbols could not be loaded for Rtnicxp.sys
Probably caused by : SYMTDI.SYS ( SYMTDI+13a4a )
Followup: MachineOwner
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: c0000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 80505c1f, address which referenced memory
Por este arquivo podemos ver que o causador do “crash” foi o arquivo SYMTDI.SYS, simplesmente jogando este arquivo em algum site de buscas, descobrimos que é um arquivo utilizado pelo Norton Antivirus. Para corrigir as telas azuis, apenas foi necessário fazer uma atualização no respectivo software.
Outro exemplo em spoiler se alguém quiser dar uma olhada:
Código:
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\apps\debugg\grr\Mini121807-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a620
Debug session time: Tue Dec 18 07:57:23.834 2007 (GMT+0)
System Uptime: 0 days 0:02:36.414
Loading Kernel Symbols
...
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
// the !analyze -v should apper in blue, you can click this text for more information
BugCheck 100000EA, {86cc2110, 86c824f0, f7998cb4, 1}
Probably caused by : ati2cqag.dll ( ati2cqag+8a31 )
Followup: MachineOwner
*** WARNING: Unable to verify timestamp for ati2cqag.dll
*** ERROR: Module load completed but symbols could not be loaded for ati2cqag.dll
Version too small
Probably caused by : ati2cqag.dll ( ati2cqag+8a31 )
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 86cc2110, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 86c824f0, Pointer to a DEFERRED_WATCHDOG object.
Arg3: f7998cb4, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
Debugging Details:
------------------
FAULTING_THREAD: 86cc2110
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT: 1
BUGCHECK_STR: 0xEA
PROCESS_NAME: csrss.exe
LAST_CONTROL_TRANSFER: from 806f2a5c to 804db8f3
STACK_TEXT:
f6a5677c 806f2a5c 00000000 00000002 bfa13a31 nt!KiDispatchInterrupt+0x7f
f6a5677c bfa13a31 00000000 00000002 bfa13a31 hal!HalpDispatchInterrupt2ndEntry+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
f6a567f8 00000000 f6a568d8 e1cca598 00000401 ati2cqag+0x8a31
STACK_COMMAND: .thread 0xffffffff86cc2110 ; kb
FOLLOWUP_IP:
ati2cqag+8a31
bfa13a31 ??
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: ati2cqag+8a31
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ati2cqag
IMAGE_NAME: ati2cqag.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 411096bd
FAILURE_BUCKET_ID: 0xEA_IMAGE_ati2cqag.dll_DATE_2004_08_04
BUCKET_ID: 0xEA_IMAGE_ati2cqag.dll_DATE_2004_08_04
Followup: MachineOwner
---------
Não poderia ser mais simples, vejam:
Probably caused by : ati2cqag.dll
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
Ficou óbvio que o erro é nos drivers de vídeo, neste caso da ATI. Solução seria atualizar ou reinstalar os mesmo.
Porém podem ver também que no diagnóstico cita isto:
PROCESS_NAME: csrss.exe
Mas este processo foi o que “crashou” por causa do driver da placa de vídeo. Nada tem a ver com o real problema da BSOD.
Se você, no caso das análises dos mini-dumps tiverem dados aleatórios de crashes ou geralmente do processo ntoskrnl.exe, é bem provável que seja falha no hardware, normalmente as memórias. Rode um memtest para ter certeza.
Em último caso, quando você já estiver pronto para formatar o disco e reinstalar o S.O., uma última dica seria rodar este comando no próprio executar do Windows:
“sfc /scannow”
Este comando vai varrer os arquivos do sistema em busca de arquivos ausentes ou danificados para substituí-los.
Obrigado, post ficou gigantesco, mas espero que tenham gostado.
Engraçado que vejo diuturnamente esses erros e os corrijo no tato, de uma maneira quase intuitiva, sensorial e surpreendentemente, com diagnósticos certeiros pelo convívio. Porém isso que o Bruno postou ajudará demais, principalmente na precisão do diagnóstico, inclusive vou imprimir lá no meu trabalho e por no mural para ajudar os colegas de profissão .
Seria bom que outros usuários que também conhecessem outros códigos de erros que geram BSOD os postassem aqui, ajudando o Bruno e transformando o tópico em um tópico dedicado à BSOD's.
Engraçado que vejo diuturnamente esses erros e os corrijo no tato, de uma maneira quase intuitiva, sensorial e surpreendentemente, com diagnósticos certeiros pelo convívio. Porém isso que o Bruno postou ajudará demais, principalmente na exatidão do diagnóstico, inclusive vou imprimir lá no meu trabalho e por no mural para ajudar os colegas de profissão .
Eu tirei de vários fóruns conceituados em overclock pela net, como amante do overclock já tive inúmeras BSOD's e pude testar todos ou quase todos que postei aí acima sempre conseguindo acertar depois o over.
Abraço.
_________________________
EDIT:
Adicionado como tirar o Reboot automático na hora do BSOD !!!
Então, os códigos que peguei e postei acima são os erros mais comuns ao rodar um teste de estabilidade ( LinX, Prime, IBT ) ou em jogos com o sistema overclockado, são BSOD's comuns ao se fazer overclock, outros códigos por outro tipo de erro eu não postei acima.
Se vcs souberem algum e quiser que eu adiciono podem falar que atualizo o tópico.
PS: só queria saber o que é o famoso "driver irql not less or equal", e com os códigos 0x0D e 0x0A (varia)... Máquina de um cliente, troquei tudo, só sobrou a placa mãe (com processador via C7 soldado). Mas acho que não tem solução.
PS: só queria saber o que é o famoso "driver irql not less or equal", e com os códigos 0x0D e 0x0A (varia)... Máquina de um cliente, troquei tudo, só sobrou a placa mãe (com processador via C7 soldado). Mas acho que não tem solução.
Dei uma procurada aqui no Adrena antes de postar e não tinha achado nada a respeito, é uma coisa muito complicada, tem muitos códigos de erro, estes que postei são mais comuns em erros ao se fazer overclock.
Erros por falha no Hardware, Drivers, Arquivos corrompidos eu não postei.
.
