-
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.
Tópico para tirar dúvidas>>>>https://forum.adrenaline.com.br/threads/obrigatoriedade-da-verificacao-em-duas-etapas-a-partir-de-24-04-2024-duvidas.712290/
Atencionamente,
Administração do Fórum Adrenaline
[ BSOD's ] Identificando os códigos de erro
- Iniciador de Tópicos onurb666
- Data de Início
ta aparecendo esse erro no meu p2 945
0x124
só que, pelo que eu li é falta de vcore, sendo que to com 3.9 com 1.45v
eu jogo até 1.55 no vcore e htt 267 para 4.0 e não adianta
sempre tela azul
memorias com respectivas latencias, tudo correto
VDDNB, ja joguei até 1.45 e nada
QPI/VTT o que é no amd? alguem sabe?
abraços
0x124
só que, pelo que eu li é falta de vcore, sendo que to com 3.9 com 1.45v
eu jogo até 1.55 no vcore e htt 267 para 4.0 e não adianta
sempre tela azul
memorias com respectivas latencias, tudo correto
VDDNB, ja joguei até 1.45 e nada
QPI/VTT o que é no amd? alguem sabe?
abraços
Última edição:
Não precisa se desculpar, isso acontece !!!
Vou conferir os que vc colocou, se não tiver eu adiciono aqui sim, com certeza quanto mais códigos e dicas melhor !!!
Abraço !
Obrigado !!!
ta aparecendo esse erro no meu p2 945
0x124
só que, pelo que eu li é falta de vcore, sendo que to com 3.9 com 1.45v
eu jogo até 1.55 no vcore e htt 267 para 4.0 e não adianta
sempre tela azul
memorias com respectivas latencias, tudo correto
VDDNB, ja joguei até 1.45 e nada
QPI/VTT o que é no amd? alguem sabe?
abraços
Eu não entendo bolufas de AMD, mas peguei um post do usuário Dupas que mostra uns códigos de erro pra AMD, dá uma olhada depois !!! ( http://www.xtremesystems.org/forums/showthread.php?t=267313 )
O que pode estar acontecendo é que mesmo aumentando as voltagens o processador não estabiliza, pode ser limite dele mesmo.
sim realmente é falta de vcore ou cores instáveis
passar de 1.55v não é muito bom não
Tem que fixar isso ae.
Qualifiquei.
Qualifiquei.
Ó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.
Primeiramente, efetuem o download do Microsoft Windows SDK (somente é necessário instalar os “debug tools”, não é necessário o Visual Studio e os outros programas/arquivos/bibliotecas ali contidos):
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
Após a instalação, devemos configurar a pasta de Symbols do WinDbg:
1) Abra o WinDbg. Caminho: "Iniciar\Debugging Tools for Windows (x86)\WinDbg.exe”
2) Crie uma pasta de destino para ele descarregar os symbols. Aqui eu uso C:\websymbols.
3) No WinDbg, vá em “File > Symbol File Path” e preencha com:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
E aperte em OK.
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:
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:
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.
Algumas referências utilizadas:
http://sharpertutorials.com/debug-windows-crash-dumps-minidump/
http://electronet.dyndns.org/computers/?p=54
http://www.computerhope.com/forum/index.php?topic=58273.0
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.
Primeiramente, efetuem o download do Microsoft Windows SDK (somente é necessário instalar os “debug tools”, não é necessário o Visual Studio e os outros programas/arquivos/bibliotecas ali contidos):
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
Após a instalação, devemos configurar a pasta de Symbols do WinDbg:
1) Abra o WinDbg. Caminho: "Iniciar\Debugging Tools for Windows (x86)\WinDbg.exe”
2) Crie uma pasta de destino para ele descarregar os symbols. Aqui eu uso C:\websymbols.
3) No WinDbg, vá em “File > Symbol File Path” e preencha com:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
E aperte em OK.
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 memoryOutro 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
---------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.
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.
Algumas referências utilizadas:
http://sharpertutorials.com/debug-windows-crash-dumps-minidump/
http://electronet.dyndns.org/computers/?p=54
http://www.computerhope.com/forum/index.php?topic=58273.0
Adicionei isso ao tópico e te qualifiquei pelo excelente post !!!
Abraços !!!
Opa, certo então! :yes:
Agora que você lembrou, te qualifiquei também, sempre esqueço dessa funcionalidade haha...
Parabéns pela iniciativa, muito util.
Pelo que li tá pedindo mais vCore.
Exatamente, tem que meter mais voltagem.
Sobe que esse topico é muito util
sobe?? Tem é que pinar esse tópico lá em cima juntinho dos outros, merece ser fixado!
Ótima atitude e iniciativa do criador do tópico! qualificado!