Entendendo A Tela Azul Do Windows

[nervoso]

Link em inglês

http://www.osr.com/ntinsider/1997/bsod/bsod.htm

Link traduzido para o português pelo Altavista

http://babelfish.altavista.com/babelfish/u...lp=en_pt&tt=url

De repente, essa pode ser uma solução para a resposta que enviei neste link de acordo com o suporte da Microsoft

http://forum.clubedohardware.com.br/index....howtopic=127375

[]'s

Rodrigo.

[PC400]

Postado Originalmente por nervoso@04 mar 2004, 01:14

Link em inglês

http://www.osr.com/ntinsider/1997/bsod/bsod.htm

Link traduzido para o português pelo Altavista

http://babelfish.altavista.com/babelfish/u...lp=en_pt&tt=url

De repente, essa pode ser uma solução para a resposta que enviei neste link de acordo com o suporte da Microsoft

http://forum.clubedohardware.com.br/index....howtopic=127375

[]'s

Rodrigo.

Vida Após A Morte? Compreendendo A Tela Azul

Ó 1997 Recursos De Sistemas Abertos de OSR, Inc.

Nós todos começamo-los. Nós todos despise os. Que é o segredo atrás de os interpretar? Neste artigo, nós delve nos princípios em telas azuis do NT, e na introspecção da oferta para ajudar determinar as causas atrás de um ruído elétrico de sistema.

Você adicionou apenas alguma funcionalidade a seu excitador... você para recarregar o sistema... suas cargas do excitador e você começa a testá-lo e... whaaam! Seu monitor instala enquanto wrenched no text-mode azul do fundo 80x50 — que sinaliza assim o início de uma outra busca 3-hour de um culpado nos guts de seu excitador. Familiar sadio?

Nós mandamos todos vir saber e amar a tela azul infamous da morte (BSOD), com seus dumps cryptic da mensagem e do hex de erro, um exemplo de que é mostrado em figura 1. Mas enquanto nós tratamos dos clientes sobre os anos, nós viemos realizar que mesmo os colaboradores experientes do excitador compreendem raramente que tipos da informação são indicados na tela azul, e que circunstâncias resultam em códigos de batente comuns. Este artigo servirá como um primer em o que vai sobre atrás da tela azul.

Figura 1 -- Você Sabe O que Este É!

De onde as telas azuis vêm?

A tela azul é maneira do NT de dizer que algo foi terrìvel erradamente e que o sistema foi um ou outro parado porque o NT próprio é confundido, ou continuar pode conduzir à perda ou ao corruption dos dados. A tela é jogada com uma chamada a uma de duas funções, KeBugCheck(...), ou KeBugCheckEx(...), ambos que são exportados para o uso por excitadores de dispositivo e por sistemas de lima (figura2).

KeBugCheck(VAGO

EM ULONG BugCheckCode

);

KeBugCheckEx(VAGO

EM ULONG BugCheckCode,

EM ULONG BUGCHECKPARAMETER1,

EM ULONG BUGCHECKPARAMETER2,

EM ULONG BUGCHECKPARAMETER3,

EM ULONG BUGCHECKPARAMETER4

);

Igure2 de F -- protótipos de KeBugCheck e de KeBugCheckEx

Ambas as chamadas da verificação do erro fazem exame de um parâmetro de BugCheckCode. Este parâmetro é sabido também como um código de BATENTE, e categoriza geralmente a razão para a parada do sistema. KeBugCheckEx(...) faz exame de 4 parâmetros adicionais que são imprimidos simplesmente na tela azul junto com o código de batente. Estes parâmetros predefiniram meanings para alguns códigos de batente padrão (alguns de que eu descreverei mais tarde), mas um excitador de dispositivo pode usar seus próprios números de código do batente com suas próprias definições para os parâmetros. KeBugCheck(...) não faz nada mais do que a chamada KeBugCheckEx(...) com o jogo de 4 parâmetros a 0.

A primeira coisa KeBugCheckEx(...) é incapacita todas as interrupções chamando KiDisableInterrupts(...). Então instala a máquina na modalidade azul da tela e despeja o BATENTE 0x0000000A do ("*** da mensagem do batente:..." em figura1). Realiza ambas estas operações com a uma chamada a HalDisplayString(...). HalDisplayString(...) faz exame de um parâmetro, que é uma corda a imprimir à tela azul. Verifica para ver se o sistema estiver já na modalidade azul da tela e se seu não, ele usa os firmware comutá-lo. Então despeja o argumento da corda na memória video do text-mode na posição atual do cursor, de que se mantem a par através das chamadas. Assim, HalDisplayString(...) pode ser usado em seu próprio excitador jogar telas azuis "feitas sob encomenda", ou imprimir mensagens informativas à tela azul que é indicada enquanto o sistema começa (por exemplo de DriverInit do sistema-inicíe o excitador). Infelizmente, se você chamar HalDisplayString(...) depois que o sistema é após a tela azul inicial, não há nenhuma maneira restaurar a tela a sua modalidade precedente (você é furado então na tela azul).

As chamadas seguintes KeGetBugMessageText de KeBugCheckEx(... )(...), uma função que traduza um código de batente ao seu texto-equivalente usando uma tabela interna do batente nomeiam. Você pode ver o jogo completo de códigos de batente predefinidos sistema e de seu texto associado no bugcodes.h arquivar no DDK. Porque a maioria de nós vêem continuamente os mesmos 4 ou 5, você pôde ser surpreendido aprender que há atualmente aproximadamente 150 códigos de batente definidos.

Neste momento KeBugCheckEx(...) chama todos os alimentadores da verificação do erro que os excitadores puderem ter registado. Um alimentador é registado chamando KeRegisterBugCheckCallback(...), e sua finalidade é geralmente preencher um amortecedor (alocado pelo chamador da rotina do registo) com o estado do dispositivo que pode ser examinado dentro de WinDbg ao eliminar erros de um dump de ruído elétrico. As rechamadas da verificação do erro são também úteis se o dispositivo que seu excitador está controlando dever ser fechado fora se o sistema falhar (um braço robotic de 2000-libras é um exemplo bom). Você pode ter os portos do giro da rechamada do excitador no dispositivo a fim incapacitá-lo.

Em seguida, o sistema chama KeDumpMachineState(...), que despeja o descanso do texto na tela. O primeiro de KeDumpMachineState(... ) tenta interpretar cada um dos 4 parâmetros que foram passados a KeBugCheckEx(...) como um endereço válido dentro de um módulo carregado, e para quando pode resolver um. Usa a função interna KiPcToFileHeader(...) fazer este. A informação KiPcToFileHeader(...) retorna para o primeiro parâmetro que com sucesso resolve, é imprimida imediatamente depois do formulário do texto do código de batente, e inclui o endereço baixo do módulo e do nome do módulo. Assim, um parâmetro do endereço pode ser alguns dos 4 parâmetros de KeBugCheckEx(... ). Eu conservarei uma descrição informative dos códigos de batente para mais tarde.

O descanso da tela é dividido em três áreas (não including a mensagem sobre contatar seu administrador). O primeiro é a área de CPUID, abaixo daquele é a área carregada do excitador, e no fundo está um traço de pilha.

A área de CPUID da tela azul inclui o CPUID, o ajuste de IRQL então a tela azul está sendo extraída (em x86 padrão HALs isto será sempre 0x1F - SYNCH_LEVEL - porque o HAL incapacita todas as interrupções quando comuta a modalidade video), e o número da configuração. O número da configuração, acessível através da variável de NtBuildNumber que é exportada da semente, é um valor 32-bit onde a mordidela elevada seja ou o ` C ', para a configuração verificada, ou o ` F ', para a configuração livre, e o descanso sejam o número baixo real da configuração de NT (1381, ou de 0x565, para NT 4.0 e alguns blocos do serviço).

Abaixo de CPUID a área é a área carregada do excitador. Cada excitador no sistema (mantido a par com o PsLoadedModuleList variável interno tem seus endereço baixo e de "selo data" mostrados nesta seção média da tela azul. Eu encontrei muito pouco uso para esta informação, mas você pode usar o selo de data certificar-se de que a versão de seu excitador que estava funcionando no sistema é essa que você pensou que era. O selo é realmente o número dos segundos desde 4:00pm, dezembro 31, 1969, a quando seu excitador foi construído, e acontece ser extraído para a direita do encabeçamento executável portátil (do PE) de um excitador. KeDumpMachineState(...) obtem-no com uma chamada a RtlImageNtHeader(...). Eu não sou demasiado grande em fazer o math com um daqueles valores do hex para obter o selo de data human-readable que representa, mas você pode verificar o selo de data do PE de uma imagem usando a utilidade do dumpbin que vem com o compilador de C visual. Datilografe o "dumpbin /headers" para começar a informação de encabeçamento do PE de seu excitador, que inclui o selo de data.

A região abaixo da seção carregada dos excitadores pode geralmente fornecer alguma introspecção em o que aconteceu (ou não). É um traço de pilha que comece no frame acima de KeBugCheckEx(...) e vá sobre acima. KeDumpMachineState(...) imprimirá para fora de tantos como frames como caberá na tela, a menos que bater um ponteiro de pilha inválido primeiramente. A pilha é lida usando a função interna KiReadStackValues(...), e cada frame indicado consiste no endereço do frame, no endereço do retorno contido no frame, nos primeiros 4 DWORDS no frame (que pode ou não pode ser parâmetros armazenados no frame), e no nome do módulo em que o endereço do retorno do frame está apontando ( de KiPcToFileHeader(...)). Se eu vir meu excitador no traço, é uma aposta boa que o dump é minha falha, e olhando o endereço do retorno que aponta em meu excitador, eu posso ver onde chamou alguma outra função que conduz à falha. Naturalmente, seu possível que meu excitador causou algum corruption em algum lugar que não estêve detectado até que alguns um tempo mais atrasado e não foram alistados na pilha.

KeBugCheckEx(...) tenta então conectar com um debugger se o sistema tiver eliminar erros da semente permitido. Não call-out ao debugger nesse ponto, though. Instead, escreve um dump de ruído elétrico se os dumps de ruído elétrico forem permitidos, e então porque sua última ação joga um limite de faturamento do debugger para invocar todo o debugger que for ativo.

Interpretando Códigos De Batente

Em a maioria de casos a informação a mais útil fornecida por uma tela azul é o código de batente e os 4 parâmetros impressos com ela. Como eu indiquei mais cedo, estes parâmetros devem ser interpretados no por-param a base do código. Nesta seção eu fornecerei mini-paro a referência do código, cobrindo esses encontrados o mais geralmente, suas causas, e como interpretar os parâmetros alistados com eles. Anote isso most of the time only a subset of KeBugCheckEx(...) parameters is used to convey information about a crash.

IRQL_NOT_LESS_OR_EQUAL (0xA)

This is one of my favorites, as I seem to encounter it more often than other types. It is thrown when the kernel or a driver determines that the current IRQL is higher than it’s supposed to be. The epicenter for most of these Bug Checks is in MmAccessFault(...), the Memory Manager’s fault handler. This function is responsible for handling page faults, and it will typically do so silently. But when the IRQL is DISPATCH_LEVEL or higher when it is invoked, it returns a STATUS_IN_PAGE_ERROR to the system page fault dispatcher. The system page fault dispatcher then promptly calls KeBugCheckEx(...) with an IRQL_NOT_LESS_OR_EQUAL.

Another place these Bug Checks can be generated is from the kernel’s worker thread dispatch function, ExpWorkerThread(...). ExpWorkerThread(...) pulls work items off a queue and calls the work routines associated with them. Upon returning from a work routine, it checks the IRQL to make sure it’s PASSIVE_LEVEL (the level it was before the work item was called). If it’s not, it throws an IRQL_NOT_LESS_OR_EQUAL. The parameters for this bug check are shown in Table 1.

IRQL_NOT_LESS_OR_EQUAL (0xA) (from worker thread)

Param1 Address of work routine that was called

Param2 IRQL that was invalid

Param3 A copy of Param1

Param4 Pointer to work item data structure

IRQL_NOT_LESS_OR_EQUAL (0xA) (from MmAccessFault)

Param1 Address that was referenced

Param2 IRQL that was invalid

Param3 Type of access (0 == read, 1 == write)

Param4 Address where reference occurred

Table 1.

KMODE_EXCEPTION_NOT_HANDLED (0x1E)

This code is generated from several places in the kernel, including the system’s exception handler. It occurs when an exception has occurred that the system was not expecting, and not able to handle via any exception handling mechanisms. One example of this occurs when MmAccessFault(...) gets a fault due to an invalid reference to a protected page. For instance, a driver that writes to a read-only page will generate it. Its parameters are shown in Table 2.

KMODE_EXCEPTION_NOT_HANDLED (0x1E)

Param1 The exception code (see NTSTATUS.H for more):

0x800000003 Breakpoint hit with no debugger active

0xC00000005 Access violation – in this case Param4 is the

address that was referenced

Param2 Address of the code where the exception occurred

Param3 First exception parameter

Param4 Second exception parameter

Table 2.

UNEXPECTED_KERNEL_MODE_TRAP (0x7F)

This code is very similar to that of KMODE_EXCEPTION_NOT_HANDLED, but is the result of a system trap for which there is no proper handler. For example, if a floating point exception occurs and the system is not prepared to handle it (like when it occurs in kernel-mode code), this exception is generated. For this type of Bug Check, the first parameter lists the CPU exception type (refer to a hardware manual to decipher it), and the other parameters are meaningless. See Table 3.

UNEXPECTED_KERNEL_MODE_TRAP (0x7F)

Param1 The CPU exception code.

Table 3.

PAGE_FAULT_IN_NON_PAGED_AREA (0x50)

This ranks up with IRQL_NOT_LESS_OR_EQUAL in terms of the frequency with which I encounter it. It is generated when a kernel-mode component accesses an address that is outside of paged memory, but there is no valid mapping for the memory. Once again, MmAccessFault(...) is the source. A driver can trigger this either by performing a data reference, or by jumping off into limbo (i.e., returning from a function that has trashed the stack). The parameters are shown in Table 4.

PAGE_FAULT_IN_NON_PAGED_AREA (0x50)

Param1 Address that was referenced

Table 4.

Conclusion

So that’s the magic behind the Blue Screen. In my experience the information presented on the Blue Screen serves more as a "hint" than anything else, and really tracking down a problem requires playing "corner the bug" inside SoftICE/NT or WinDbg. Both debuggers will obtain control at the point KeBugCheckEx(...) is called, so that you can sniff around for more clues. However, most of the time you have to watch the bug occur before the fault to really understand it.

NT Insider 1997 On-line Articles

Corrige os errinhos aí cara , é muito bom esse tópico !

[Flucas]

O que é o excitador no windows?