Application Verifier - Códigos de parada - Noções básicas

Os códigos de parada a seguir estão contidos no conjunto básico de testes.

Exceções interrompem detalhes

Tente executar código em memória não executável (primeira chance).

Essa parada será gerada se o aplicativo estiver tentando executar o código de um endereço que não seja executável ou gratuito. Para depurar esta parada:

• u <parameter2> – desmontar o código culpado
• Parâmetro .exr3>< – exibir as informações de exceção
• Parâmetro .cxr4 <> – exibir as informações de contexto de exceção
• kb – exiba o rastreamento de pilha para o momento em que a exceção foi gerada.

• Parâmetro 1 - Endereço que está sendo acessado.
• Parâmetro 2 - Código executando acesso inválido.
• Parâmetro 3 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 4 - Registro de contexto. Use .cxr para exibi-lo.

• Camada de teste: Exceções
• Parar ID: FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Parar código: 650
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Identificadores interrompem detalhes

Exceção de identificador inválida para rastreamento de pilha atual.

Essa parada será gerada se a função na parte superior da pilha passar um identificador inválido para rotinas do sistema. Normalmente, um comando 'kb' simples revelará qual é o valor do identificador passado (ele deve ser um dos parâmetros - geralmente o primeiro). Se o valor for nulo, isso estará claramente errado. Se o valor parecer ok, você precisará usar a extensão do depurador '!htrace' para obter um histórico de operações pertencentes a esse valor de identificador. Na maioria dos casos, o valor do identificador é usado após ser fechado.

• parâmetro 1 – Não usado.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Manipula
• Parar ID: INVALID_HANDLE
• Parar código: 300
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Índice TLS inválido usado para rastreamento de pilha atual.

Essa parada será gerada se a função na parte superior da pilha passar um índice TLS inválido para rotinas do sistema TLS. Normalmente, um comando 'kb' simples revelará o que está errado. O bug típico aqui é assumir um determinado valor para um índice TLS em vez de chamar 'TlsAlloc'. Isso pode acontecer supondo que você sempre obtenha o valor N e, portanto, não é necessário chamar 'TlsAlloc'. Com mais frequência, é devido a uma variável não inicializada.

• Parâmetro 1 -Índice  TLS inválido.
• Parâmetro 2 - Parte inferior esperada do índice.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Manipula
• Parar ID: INVALID_TLS_VALUE
• Parar código: 301
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Parâmetros inválidos para a chamada WaitForMultipleObjects.

Essa parada será gerada se a função na parte superior da pilha chamada 'WaitForMultipleObjects' com NULL como o endereço da matriz de identificadores aguardar ou com zero como o número de identificadores. Um comando 'kb' simples revelará a função que chama essa API incorretamente.

• Parâmetro 1 - Endereço do vetor de identificadores de objeto.
• Parâmetro 2 - Número de identificadores.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Manipula
• Parar ID: INCORRECT_WAIT_CALL
• Parar código: 302
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Identificador NULL passado como parâmetro. Um identificador válido deve ser usado.

Essa parada será gerada se a função na parte superior da pilha passar um identificador NULL para rotinas do sistema. Normalmente, um comando 'kb' simples revelará qual é o valor do identificador passado (ele deve ser um dos parâmetros, geralmente o primeiro).

• Parâmetro 1 - Usando o identificador NULL
• Parâmetro 2 - Não usado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Manipula
• Parar ID: NULL_HANDLE
• Parar código: 303
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Aguardando um identificador de thread no DllMain.

Essa parada será gerada se o thread atual estiver executando código dentro da função 'DllMain' de uma das DLLs carregadas no processo atual e chamar 'WaitForSingleObject' ou 'WaitForMultipleObjects' para aguardar em um identificador de thread no mesmo processo. Isso provavelmente levará a um deadlock porque o identificador de thread não será sinalizado, a menos que o segundo thread esteja saindo. Quando o segundo thread chama 'ExitThread', ele tenta adquirir o bloqueio do carregador de DLL e, em seguida, chama 'DllMain' (DLL_THREAD_DETACH) para todas as DLLs no processo atual. Como o bloqueio do carregador pertence ao primeiro thread (aquele que está aguardando no identificador de thread), os dois threads ficarão em deadlock.

• Parâmetro 1 - Identificador de thread.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Manipula
• Parar ID: WAIT_IN_DLLMAIN
• Parar código: 304
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Tipo de objeto incorreto para identificador.

Essa parada será gerada se o thread atual estiver chamando uma API com um identificador para um objeto com um tipo de objeto incorreto. Por exemplo, chamar 'SetEvent' com um identificador de semáforo como parâmetro gera essa parada. Para depurar esta parada:

• kb – para exibir o rastreamento de pilha atual. O culpado provavelmente é a DLL que está chamando verifier.dll
• du <parameter2> – para exibir o tipo real do identificador. O valor do identificador é parameter1. No exemplo anterior, isso exibe "Semáforo".
• du <parameter3> – para exibir o tipo de objeto esperado pela API. No exemplo anterior, esse nome é "Evento".
• !htrace <parameter1> – pode ser útil, pois exibe o rastreamento de pilha para as operações de abertura/fechamento recentes nesse identificador.

• Parâmetro 1 - Manipular valor.
• Parâmetro 2 - Nome do tipo de objeto. Use du para exibi-lo
• Parâmetro 3 -Nome do tipo de  objeto esperado. Use du para exibi-lo
• parâmetro 4 – Não usado.

• Camada de teste: Manipula
• Parar ID: INCORRECT_OBJECT_TYPE
• Parar código: 305
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes de interrupção de heaps

Erro desconhecido.

Essa mensagem poderá acontecer se o erro encontrado não puder ser classificado de outra maneira. Não usado agora.

• Parâmetro 1 - Não usado
• Parâmetro 2 - Não usado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: UNKNOWN_ERROR
• Parar código: 0x1
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção de violação de acesso.

Essa é a parada mais comum do verificador de aplicativos. Normalmente, isso é causado por um erro de sobrecarga de buffer. O verificador de heap coloca uma página não acessível no final de uma alocação de heap e uma sobrecarga de buffer causará uma exceção tocando nesta página. Para depurar essa parada, identifique o endereço de acesso que causou a exceção e use o seguinte comando de depurador:

• !heap -p -a ACCESS_ADDRESS - Este comando fornece detalhes sobre a natureza do erro e qual bloco de heap é invadido. Ele também fornece o rastreamento de pilha para a alocação de blocos. Há outras causas para essa parada, por exemplo, acessar um bloco de heap após ser liberado. O mesmo comando de depurador é útil para esse caso.

• Parâmetro 1 -Endereço  inválido causando a exceção
• Parâmetro 2 - Endereço de código executando o acesso inválido
• Parâmetro 3 -Registro de  exceção
• Parâmetro 4 -Registro de  contexto

• Camada de teste: Montes
• Parar ID: ACCESS_VIOLATION
• Parar código: 0x2
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Acesso multithreaded em um heap criado com HEAP_NO_SERIALIZE sinalizador.

Um heap criado com HEAP_NO_SERIALIZE sinalizador não deve ser acessado simultaneamente de dois threads. Se essa situação for detectada, você receberá esta mensagem. A maneira típica de essa situação entrar em um programa é vinculando-se a uma versão de thread único do C-runtime. O Visual C++, por exemplo, pode vincular estaticamente essa biblioteca quando sinalizadores apropriados são usados. Em seguida, os desenvolvedores esquecem esse detalhe e usam vários threads. O bug é muito difícil de depurar na vida real porque ele aparecerá como dados misteriosos corrompidos.

• Parâmetro 1 - Heap no qual a operação acontece.
• Parâmetro 2 - ID do thread para o proprietário atual da seção crítica do heap.
• Parâmetro 3 - ID do thread atual tentando entrar no heap.
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: UNSYNCHRONIZED_ACCESS
• Parar código: 0x3
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Solicitação de tamanho extremo.

Essa mensagem será gerada se, em uma operação 'HeapAlloc' ou 'HeapReAlloc', o tamanho do bloco estiver acima de qualquer valor razoável. Normalmente, esse valor é 0x80000000 em plataformas de 32 bits e significativamente maior em plataformas de 64 bits.

• Parâmetro 1 - Heap no qual a operação acontece.
• Parâmetro 2 - Tamanho solicitado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: EXTREME_SIZE_REQUEST
• Parar código: 0x4
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Identificador de heap com assinatura incorreta.

As estruturas de heap são marcadas com um valor mágico. Se o identificador de heap usado na chamada para uma interface de heap não tiver esse padrão, essa parada será gerada. Esse bug pode acontecer se de alguma forma a estrutura do heap interno tiver sido corrompida (corrupção aleatória) ou simplesmente um valor falso for usado como um identificador de heap. Para obter uma lista de valores válidos de identificador de heap, use o seguinte comando de depurador:

• !heap -p

Observe que se você apenas alternar um identificador de heap válido com outro válido em uma operação de heap, você não obterá essa parada (a alça parece válida, afinal). No entanto, o verificador de heap detecta essa situação e a relata com SWITCHED_HEAP_HANDLE parar.

• Parâmetro 1 - Identificador de heap usado na chamada para uma interface de heap
• Parâmetro 2 - Não usado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: BAD_HEAP_HANDLE
• Parar código: 0x5
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Ponteiro de heap corrompido ou usando heap errado.

Normalmente, isso acontece se um bloco é alocado em um heap e liberado em outro. Use o comando de depurador '!heap -p' para obter uma lista de todos os valores de identificador de heap válidos. O exemplo mais comum é uma alocação msvcrt usando 'malloc' emparelhado com uma desalocação kernel32 usando 'HeapFree'.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Heap onde o bloco foi originalmente alocado.

• Camada de teste: Montes
• Parar ID: SWITCHED_HEAP_HANDLE
• Parar código: 0x6
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Bloco de heap já liberado.

Essa situação ocorrerá se o bloco for liberado duas vezes. Os blocos liberados são marcados de forma especial e são mantidos por um tempo em uma fila gratuita atrasada. Se um programa de buggy tentar liberar o bloco novamente, isso será capturado - supondo que o bloco não foi desativado da fila gratuita atrasada e sua memória reutilizado para outras alocações. A profundidade da fila livre de atraso está na ordem de milhares de blocos, portanto, há boas chances de que a maioria dos frees duplos seja capturada.

• Parâmetro 1 - Identificador de heap para o heap que possui o bloco.
• Parâmetro 2 - Bloco heap sendo libertado novamente.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: DOUBLE_FREE
• Parar código: 0x7
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Bloco de heap corrompido.

Esse é um erro genérico emitido se a corrupção no bloco de heap não puder ser colocada em uma categoria mais específica.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Reservado

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK
• Parar código: 0x8
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Tente destruir o heap do processo.

É um erro tentar destruir o heap de processo padrão (aquele retornado pela interface 'GetProcessHeap()').

• Parâmetro 1 - Identificador de heap usado com HeapDestroy.
• Parâmetro 2 - Não usado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: DESTROY_PROCESS_HEAP
• Parar código: 0x9
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada gerada no código do heap.

Essa parada será gerada se, durante a execução do código do gerenciador de heap, uma violação de acesso for gerada em situações ilegítimas. Há poucas situações em que isso está ok, por exemplo, ao chamar 'HeapValidate()' ou 'HeapSize()'. As informações de registro de exceção (terceiro parâmetro) podem ser usadas para localizar o contexto exato da exceção. Use os seguintes comandos de depurador para isso:

• dd parameter2 L2
• .exr first_dword
• .cxr second_dword

Normalmente, essa parada acontece se houver alguma corrupção aleatória nas estruturas de heap internas.

• Parâmetro 1 - Heap envolvido na operação.
• Parâmetro 2 -Registro de  exceção.
• Parâmetro 3 - Registro de contexto.
• Parâmetro 4 -Código de  exceção (C0000005 - violação de acesso)

• Camada de teste: Montes
• Parar ID: UNEXPECTED_EXCEPTION
• Parar código: 0xA
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção gerada durante a verificação do cabeçalho do bloco de heap.

Essa situação acontece se realmente não pudermos determinar nenhum tipo específico de corrupção para o bloco. Por exemplo, quando o endereço do bloco de heap passado para uma operação livre de heap aponta para uma área de memória não acessível (ponteiro corrompido, ponteiro não inicializado etc.).

• Parâmetro 1 - Identificador de heap para o heap que possui o bloco.
• Parâmetro 2 - Bloco heap corrompido.
• Parâmetro 3 - Tamanho do bloco ou zero se o tamanho não puder ser determinado.
• parâmetro 4 – Não usado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_HEADER
• Parar código: 0xB
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção gerada durante a verificação do bloco de heap.

Essa situação acontece se realmente não pudermos determinar nenhum tipo específico de corrupção para o bloco. Por exemplo, você obterá isso se durante uma operação livre de heap passar um endereço que aponte para uma área de memória não acessível. Isso também pode acontecer para situações gratuitas duplas se não encontrarmos o bloco entre blocos de heap de página inteira e o investigarmos como um bloco de heap de páginas leves.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Reservado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_PROBING
• Parar código: 0xC
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Bloco heap corrompido após ser libertado.

Essa situação ocorrerá se um bloco de memória for gravado após ser liberado.

• Parâmetro 1 - Identificador de heap para o heap que possui o bloco.
• Parâmetro 2 - Bloco heap corrompido.
• Parâmetro 3 - Tamanho do bloco ou zero se o tamanho não puder ser determinado.
• parâmetro 4 – Não usado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_HEADER
• Parar código: 0xD
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Padrão de infixo corrompido para bloco de heap liberado.

Os blocos liberados às vezes são marcados como não acessíveis e um programa que os toca acessará violará (parada de verificador diferente). Em outros casos (por exemplo, um heap de página de luz), o bloco é marcado com um padrão mágico e será mantido por um tempo. Eventualmente, de forma FIFO, os blocos são realmente libertados. Neste momento, o padrão de infixo é verificado e, se ele tiver sido modificado, você obterá essa interrupção. A pilha no momento do intervalo não é relevante. Você precisa descobrir a natureza do bloco e do código para examinar o código que pode estar errado.

• Parâmetro 1 - Identificador de heap para o heap que possui o bloco.
• Parâmetro 2 - Bloco heap sendo liberado.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Reservado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_FREED_HEAP_BLOCK
• Parar código: 0xE
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Padrão de sufixo corrompido para o bloco de heap.

Normalmente, isso ocorre para erros de sobrecarga de buffer. Às vezes, o verificador de aplicativos coloca páginas não acessíveis no final da alocação e os excessos de buffer causarão uma violação de acesso e, às vezes, o bloco de heap é seguido por um padrão mágico. Se esse padrão for alterado quando o bloco for liberado, você obterá essa interrupção. Essas quebras podem ser muito difíceis de depurar porque você não tem o momento real em que a corrupção aconteceu. Você só tem acesso ao momento livre (ou seja, "stop happened here") e ao rastreamento da pilha de alocação ('!heap -p -a HEAP_ADDRESS')

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Reservado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_SUFFIX
• Parar código: 0xF
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Carimbo de início corrompido para bloco de heap.

Isso acontece para subexecuções de buffer.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 -Valor  de selo corrompido.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_START_STAMP
• Parar código: 0x10
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Carimbo de fim corrompido para bloco de heap.

Isso acontece para subexecuções de buffer.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 -Valor  de selo corrompido.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_END_STAMP
• Parar código: 0x11
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Padrão de prefixo corrompido para o bloco de heap.

Isso acontece para subexecuções de buffer.

• Parâmetro 1 - Identificador de heap usado na chamada.
• Parâmetro 2 - Bloco heap envolvido na operação.
• Parâmetro 3 - Tamanho do bloco de heap.
• Parâmetro 4 - Reservado.

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_BLOCK_PREFIX
• Parar código: 0x12
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Violação de acesso de primeira chance para o rastreamento de pilha atual.

Essa é a parada mais comum do verificador de aplicativos. Normalmente, isso é causado por um erro de sobrecarga de buffer. O verificador de heap coloca uma página não acessível no final de uma alocação de heap e uma sobrecarga de buffer causará uma exceção tocando nesta página. Para depurar essa parada, identifique o endereço de acesso que causou a exceção e use o seguinte comando de depurador:

• !heap -p -a ACCESS_ADDRESS

Esse comando fornecerá detalhes sobre a natureza do erro e qual bloco de heap é invadido. Ele também fornecerá o rastreamento de pilha para a alocação de blocos. Há várias outras causas para essa parada, por exemplo, acessar um bloco de heap após ser liberado. O mesmo comando de depurador será útil para esse caso.

• Parâmetro 1 - Endereço inválido causando a exceção.
• Parâmetro 2 - Endereço de código executando o acesso inválido.
• Parâmetro 3 -Registro de  exceção.
• Parâmetro 4 - Registro de contexto.

• Camada de teste: Montes
• Parar ID: FIRST_CHANCE_ACCESS_VIOLATION
• Parar código: 0x13
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Contagem de lista de heap de processo inválida.

Essa mensagem poderá acontecer se, ao chamar GetProcessHeaps, o gerenciador de heap de páginas detectar algumas inconsistências internas. Isso pode ser causado por alguma corrupção aleatória no espaço do processo.

• Parâmetro 1 -  Contagem de heap real.
• Parâmetro 2 - Contagem de heap de páginas.
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Montes
• Parar ID: CORRUPTED_HEAP_LIST
• Parar código: 0x14
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes da parada de vazamento

Uma alocação de heap foi vazada.

Essa parada será gerada se o proprietário dll da alocação tiver sido descarregado dinamicamente ao possuir recursos.

• Parâmetro 1 - Endereço da alocação vazada. Execute !heap -p -a <endereço> para obter informações adicionais sobre a alocação.
• Parâmetro 2 - Endereçar ao rastreamento da pilha de alocação. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: ALOCAÇÃO
• Parar código: 0x900
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Um IDENTIFICADOR foi vazado.

Essa parada será gerada se a dll do proprietário do identificador tiver sido descarregada dinamicamente ao possuir recursos. Para depurar essa parada: execute !htrace parameter1 para obter informações adicionais sobre o identificador.

• Parâmetro 1 - Valor do identificador vazado. Execute o identificador< !htrace >para obter informações adicionais sobre o identificador se o rastreamento de identificador estiver habilitado.
• Parâmetro 2 - Endereçar ao rastreamento da pilha de alocação. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: MANEJAR
• Parar código: 0x901
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Um HKEY vazou.

Essa parada será gerada se a dll do proprietário da chave do Registro tiver sido descarregada dinamicamente ao possuir recursos.

• Parâmetro 1 - Valor do HKEY vazado.
• Parâmetro 2 - Endereçar ao rastreamento da pilha de alocação. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: REGISTRO
• Parar código: 0x902
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Uma reserva virtual foi vazada.

Essa parada será gerada se a dll do proprietário da reserva virtual tiver sido descarregada dinamicamente ao possuir recursos.

• Parâmetro 1 - Endereço de reserva vazado.
• Parâmetro 2 - Endereçar ao rastreamento da pilha de alocação. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: VIRTUAL_RESERVATION
• Parar código: 0x903
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Um BSTR vazou.

Essa parada será gerada se a dll do proprietário do SysString foi descarregada dinamicamente enquanto possuía recursos.

• Parâmetro 1 - Endereço do BSTR vazado. Execute !heap -p -a <endereço> para obter informações adicionais sobre a alocação.
• Parâmetro 2 - Endereçar ao rastreamento da pilha de alocação. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: SYSSTRING
• Parar código: 0x904
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Uma notificação de energia não foi registrada.

Essa parada será gerada se a dll for registrada para notificação de energia e tiver sido descarregada dinamicamente sem registro.

• Parâmetro 1 - Endereço do registro de notificação de energia.
• Parâmetro 2 - Endereço para o rastreamento de pilha de registro. Execute o endereço< dps >para exibir a pilha de alocação.
• Parâmetro 3 - Endereço do nome dll do proprietário. Execute o endereço< du >para ler o nome dll.
• Parâmetro 4 - Base do proprietário dll. Execute .reload <dll_name> = <endereço> para recarregar a dll do proprietário. Use 'lm' para obter mais informações sobre os módulos carregados e descarregados.

• Camada de teste: Vazar
• Parar ID: POWER_NOTIFICATION
• Parar código: 0x905
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes da parada de bloqueios

O Thread não pode ter uma seção crítica.

Essa parada será gerada se um thread (a ID do thread for o parâmetro1) for encerrado, suspenso ou estiver em um estado (o thread de trabalho terminou um item de trabalho) no qual ele não pode manter uma seção crítica. O thread atual é o culpado. Para depurar essa parada, use os seguintes comandos de depurador:

• kb – para obter o rastreamento de pilha atual. Se o thread atual for o proprietário da seção crítica, ele provavelmente chamará ExitThread. O thread atual deve ter liberado a seção crítica antes de sair. Se o thread atual estiver chamando TerminateThread ou SuspendThread, ele não deverá fazer isso para um thread que contém uma seção crítica.
• !cs -s <parameter2> – informações de despejo sobre esta seção crítica.
• ln <parameter2> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica vazada.
• parâmetro dps4>< – para despejar o rastreamento de pilha para esta inicialização de seção crítica.

• Parâmetro 1 - ID do thread.
• Parâmetro 2 - Endereço de seção crítico.
• Parâmetro 3 - Endereço de informações de depuração de seção crítica.
• Parâmetro 4 -Rastreamento de pilha de  inicialização de seção crítica.

• Camada de teste: Fechaduras
• Parar ID: EXIT_THREAD_OWNS_LOCK
• Parar código: 0x200
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Descarregando a DLL que contém uma seção crítica ativa.

Essa parada será gerada se uma DLL tiver uma variável global contendo uma seção crítica e a DLL for descarregada, mas a seção crítica não tiver sido excluída. Para depurar essa parada, use os seguintes comandos de depurador:

• du <parameter3> – para despejar o nome da DLL culpada.
• .reload dllname ou .reload dllname = <parameter4> – para recarregar os símbolos para essa DLL.
• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica vazada.
• parâmetro dps2>< – para despejar o rastreamento de pilha para esta inicialização de seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Rastreamento de pilha de  inicialização de seção crítica.
• Parâmetro 3 - Endereço de nome DLL.
• Parâmetro 4 - Endereço base da DLL.

• Camada de teste: Fechaduras
• Parar ID: LOCK_IN_UNLOADED_DLL
• Parar código: 0x201
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Liberando o bloco de heap que contém uma seção crítica ativa.

Essa parada será gerada se uma alocação de heap contiver uma seção crítica, a alocação for liberada e a seção crítica não tiver sido excluída. Para depurar essa parada, use os seguintes comandos de depurador:

• !cs -s <(parâmetro1)> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica vazada.
• parâmetro dps2>< – para despejar o rastreamento de pilha para esta inicialização de seção crítica.
• < parameter3> e <parameter4> podem ajudar a entender onde esse bloco de heap foi alocado (o tamanho da alocação provavelmente é significativo).

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Rastreamento de pilha de  inicialização de seção crítica.
• Parâmetro 3 - Endereço de bloco de heap.
• Parâmetro 4 -Tamanho do bloco heap .

• Camada de teste: Fechaduras
• Parar ID: LOCK_IN_FREED_HEAP
• Parar código: 0x202
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Seção crítica inicializada dupla ou corrompida.

Normalmente, essa parada será gerada se uma seção crítica tiver sido inicializada mais de uma vez. Nesse caso, parâmetro3 e parameter4 são os endereços de rastreamento de pilha para duas dessas inicializações. Outras vezes é possível obter essa parada se a seção crítica ou sua estrutura de informações de depuração tiver sido corrompida. Nesse segundo caso, é possível que os parâmetros3 e parameter4 sejam inválidos e inúteis. Para depurar esta parada:

• !cs -s -d <parâmetro2> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso pode ajudar a identificar a seção crítica se essa for uma variável global.
• parâmetro dps3>< e dps <parameter4> – para identificar os dois caminhos de código para inicializar esta seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Endereço da estrutura de informações de depuração encontrada na lista ativa.
• Parâmetro 3 -Primeiro rastreamento de pilha de  inicialização.
• Parâmetro 4 - Segundo rastreamento de pilha de inicialização.

• Camada de teste: Fechaduras
• Parar ID: LOCK_DOUBLE_INITIALIZE
• Parar código: 0x203
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Memória livre que contém uma seção crítica ativa.

Essa parada será gerada se a memória que contém uma seção crítica for liberada, mas a seção crítica não tiver sido excluída usando DeleteCriticalSection. Para depurar essa parada, use os seguintes comandos de depurador:</p.>

• !cs -s -d <parâmetro2> – informações de despejo sobre esta seção crítica.
• parâmetro dps3>< – para identificar o caminho do código para inicializar esta seção crítica.

Na maioria dos casos, o verificador de bloqueio detecta seções críticas imediatamente vazadas contidas em uma alocação de heap, um intervalo de DLL, uma alocação de memória virtual ou um intervalo de memória mapViewOfFile mapeado e emite paradas diferentes nesses casos. Portanto, há muito poucos casos para esta parada de verificador. O bloqueio deve estar em um intervalo de memória liberado pelo código do modo kernel ou liberado entre processos por APIs como VirtualFreeEx. Normalmente, essa parada será encontrada se uma parada anterior (por exemplo, LOCK_IN_FREED_HEAP ou LOCK_IN_UNLOADED_DLL) foi continuada clicando em 'g' no console do depurador.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Endereço de informações de depuração de seção crítica.
• Parâmetro 3 -Rastreamento de pilha de  inicialização de seção crítica.
• parâmetro 4 – Não usado.

• Camada de teste: Fechaduras
• Parar ID: LOCK_IN_FREED_MEMORY
• Parar código: 0x204
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Seção crítica corrompida.

Essa parada será gerada se o campo DebugInfo da seção crítica estiver apontando memória liberada. Normalmente, outra estrutura de DebugInfo válida é encontrada na lista de seções críticas ativas. Sem corrupção, os dois ponteiros devem ser idênticos. Para depurar essa parada, use os seguintes comandos de depurador:

• !cs -s -d <parâmetro3> – informações de despejo sobre esta seção crítica com base no conteúdo atual da estrutura de informações de depuração encontrada na lista ativa (essa estrutura raramente é corrompida, portanto, geralmente essas informações são confiáveis).
• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica com base no conteúdo atual da estrutura de seção crítica (a estrutura já está corrompida, então, às vezes, essas informações NÃO são confiáveis).
• parâmetro dps4>< – para identificar o caminho do código para inicializar esta seção crítica.

Despeje a seção crítica no parâmetro de endereço1>< e procure o padrão de corrupção. Com bons símbolos para ntdll.dl, você pode usar os seguintes comandos:

• dt ntdll!_RTL_CRITICAL_SECTION LOCK_ADDRESS
• dt ntdll!_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Endereço de informações de depuração inválidas desta seção crítica.
• Parâmetro 3 - Endereço das informações de depuração encontradas na lista ativa.
• Parâmetro 4 -Rastreamento de pilha de  inicialização.

• Camada de teste: Fechaduras
• Parar ID: LOCK_CORRUPTED
• Parar código: 0x205
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Thread do proprietário da seção crítica inválido.

Essa parada será gerada se a ID do thread do proprietário for inválida no contexto atual. Para depurar esta parada:

• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Possuindo thread.
• Parâmetro 3 - Thread  proprietário esperado.
• Parâmetro 4 - Endereço de informações de depuração de seção crítica.

• Camada de teste: Fechaduras
• Parar ID: LOCK_INVALID_OWNER
• Parar código: 0x206
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Contagem de recursão de seção crítica inválida.

Essa parada será gerada se o campo contagem de recursão da estrutura de seção crítica for inválido no contexto atual. Para depurar esta parada:

• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Contagem de recursão.
• Parâmetro 3 -  Contagem de recursão esperada.
• Parâmetro 4 - Endereço de informações de depuração de seção crítica.

• Camada de teste: Fechaduras
• Parar ID: LOCK_INVALID_RECURSION_COUNT
• Parar código: 0x207
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Excluindo a seção crítica com contagem de bloqueio inválida.

Essa parada será gerada se uma seção crítica pertencer a um thread se ela for excluída ou se a seção crítica não for inicializada. Para depurar esta parada:

• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica. Se o thread proprietário for 0, a seção crítica não foi inicializada.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Contagem de  bloqueios.
• Parâmetro 3 -  Contagem de bloqueios esperada.
• Parâmetro 4 - Possuindo thread.

• Camada de teste: Fechaduras
• Parar ID: LOCK_INVALID_LOCK_COUNT
• Parar código: 0x208
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Seção crítica super-liberada ou corrompida.

Essa parada será gerada se uma seção crítica for lançada mais vezes do que o thread atual a adquiriu. Para depurar esta parada:

• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• !cs -s -d <parameter4> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Contagem de  bloqueios.
• Parâmetro 3 -  Contagem de bloqueios esperada.
• Parâmetro 4 - Endereço de informações de depuração de seção crítica.

• Camada de teste: Fechaduras
• Parar ID: LOCK_OVER_RELEASED
• Parar código: 0x209
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Seção crítica não inicializada.

Essa parada será gerada se uma seção crítica for usada sem ser inicializada ou depois de ter sido excluída. Para depurar esta parada:

• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso deve ajudar a identificar a seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Endereço de informações de depuração de seção crítica.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Fechaduras
• Parar ID: LOCK_NOT_INITIALIZED
• Parar código: 0x210
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

A seção crítica já está inicializada.

Essa parada será gerada se uma seção crítica for reinicializada pelo thread atual. Para depurar esta parada:

• !cs -s <parameter1> ou !cs -s -d <parameter2> – informações de despejo sobre esta seção crítica.
• ln <parameter1> – para mostrar símbolos próximos ao endereço da seção crítica. Isso pode ajudar a identificar a seção crítica se essa for uma variável global.
• parâmetro dps3 <> – para identificar o caminho do código para a primeira inicialização desta seção crítica.
• kb – para exibir o rastreamento de pilha atual, que está reinicializando esta seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Endereço de informações de depuração de seção crítica.
• Parâmetro 3 -Primeiro rastreamento de pilha de  inicialização. Usar dps para despejá-lo se não for NULL
• parâmetro 4 – Não usado.

• Camada de teste: Fechaduras
• Parar ID: LOCK_ALREADY_INITIALIZED
• Parar código: 0x211
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Liberação de memória virtual que contém uma seção crítica ativa.

Essa parada será gerada se o thread atual estiver chamando VirtualFree em um bloco de memória que contenha uma seção crítica ativa. O aplicativo deve chamar DeleteCriticalSection nesta seção crítica antes de liberar essa memória.

• kb – para exibir o rastreamento de pilha atual, que está chamando VirtualFree. O provável culpado é a DLL que chama VirtualFree.
• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• parâmetro dps2>< – para identificar o caminho do código para a inicialização desta seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Rastreamento de pilha de  inicialização de seção crítica.
• Parâmetro 3 - Endereço do bloco de memória.
• Parâmetro 4 -Tamanho do bloco de  memória.

• Camada de teste: Fechaduras
• Parar ID: LOCK_IN_FREED_VMEM
• Parar código: 0x212
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Desmapear a região de memória que contém uma seção crítica ativa.

Essa parada será gerada se o thread atual estiver chamando UnmapViewOfFile em um bloco de memória que contém uma seção crítica ativa. O aplicativo deve chamar DeleteCriticalSection nesta seção crítica antes de cancelar omaps dessa memória.

• kb – para exibir o rastreamento de pilha atual, que está chamando UnmapViewOfFile . O provável culpado é a DLL que chama UnmapViewOfFile.
• !cs -s <parâmetro1> – informações de despejo sobre esta seção crítica.
• parâmetro dps2>< – para identificar o caminho do código para a inicialização desta seção crítica.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 -Rastreamento de pilha de  inicialização de seção crítica.
• Parâmetro 3 - Endereço do bloco de memória.
• Parâmetro 4 -Tamanho do bloco de  memória.

• Camada de teste: Fechaduras
• Parar ID: LOCK_IN_UNMAPPED_MEM
• Parar código: 0x213
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O thread atual não possui seções críticas.

Essa parada será gerada se o thread atual estiver chamando LeaveCriticalSection, mas, de acordo com a contabilidade interna do verificador, ele não possui nenhuma seção crítica. Se \<parameter2\> for zero, provavelmente esse será um bug no thread atual. Ele tenta deixar uma seção crítica que não inseriu ou talvez esteja chamando LeaveCriticalSection mais vezes do que chamou EnterCriticalSection para a mesma seção crítica. Se \<parameter2\> não for zero (é um número inteiro negativo), as estruturas de dados internas do verificador provavelmente estarão corrompidas.

• Parâmetro 1 - Endereço de seção crítico.
• Parâmetro 2 - Número de seções críticas pertencentes ao thread atual.
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Fechaduras
• Parar ID: THREAD_NOT_LOCK_OWNER
• Parar código: 0x214
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Usando a seção crítica que é privada para outra DLL.

Essa parada será gerada se o thread atual tentar usar um bloqueio privado que reside dentro de outra DLL. Por exemplo, a.dll tenta inserir uma seção crítica definida dentro de ntdll.dll. Bloqueios privados não podem ser usados em DLLs.

• Parâmetro 1 - Endereço de seção crítico.
• parâmetro 2 – Não usado.
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Fechaduras
• Parar ID: LOCK_PRIVATE
• Parar código: 0x215
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes da parada SRWLock

O bloqueio SRW não é inicializado.

Essa parada será gerada se um thread estiver tentando usar o bloqueio SRW (Param1) que não é inicializado. Para depurar essa parada, use 'kb' para obter o rastreamento de pilha atual. É aqui que o bloqueio SRW está sendo usado. O bloqueio SRW deve ser inicializado usando 'InitializeSRWLock' antes que ele possa ser usado.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - Não usado
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: SRWLock
• Parar ID: NOT_INITIALIZED
• Parar código: 0x250
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O bloqueio SRW já está inicializado.

Essa parada será gerada se o bloqueio SRW (Param1) estiver sendo inicializado novamente. Se o bloqueio SRW estiver sendo usado ativamente por outros threads, a re inicialização do bloqueio resultará em um comportamento imprevisível do aplicativo, incluindo travamentos e falhas. O rastreamento da pilha de inicialização pode mostrar uma aquisição se o bloqueio SRW foi inicializado estaticamente. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que o bloqueio SRW está sendo inicializado novamente.
• parâmetro dps3>< – para obter o rastreamento de pilha de inicialização de bloqueio SRW. Esse rastreamento de pilha pode mostrar uma aquisição se o bloqueio foi inicializado estaticamente.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - ThreadId do thread que inicializou o bloqueio SRW.
• Parâmetro 3 - Endereço do rastreamento da pilha de inicialização. Use o endereço< dps >para ver onde o bloqueio SRW foi inicializado.
• Parâmetro 4 - Não usado

• Camada de teste: SRWLock
• Parar ID: ALREADY_INITIALIZED
• Parar código: 0x251
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Acquire-Release incompatível no bloqueio SRW.

Essa parada será gerada se o bloqueio SRW (Param1) estiver sendo liberado com uma API de versão incorreta. Se o bloqueio SRW foi adquirido para acesso compartilhado e está sendo liberado usando a API de versão exclusiva ou o bloqueio SRW foi adquirido para acesso exclusivo e está sendo liberado usando a API de versão compartilhada. Isso pode resultar em um comportamento imprevisível do aplicativo, incluindo travamentos e falhas. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que o bloqueio SRW está sendo liberado usando a API errada.
• parâmetro dps3 <> – para obter o rastreamento de pilha de aquisição de bloqueio SRW.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - ThreadId do thread que adquiriu o bloqueio SRW.
• Parâmetro 3 - Endereço do rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.
• Parâmetro 4 - Não usado

• Camada de teste: SRWLock
• Parar ID: MISMATCHED_ACQUIRE_RELEASE
• Parar código: 0x252
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O bloqueio SRW está sendo adquirido recursivamente pelo mesmo thread.

Essa parada será gerada se o bloqueio SRW (Param1) estiver sendo adquirido recursivamente pelo mesmo thread. Isso resultará em um deadlock e o thread será bloqueado indefinidamente. A aquisição recursiva de um bloqueio SRW no modo exclusivo causará um deadlock. A aquisição recursiva de um bloqueio SRW no modo compartilhado causará um deadlock quando houver um thread aguardando acesso exclusivo. Considere o exemplo abaixo: – O Thread A adquire o bloqueio SRW no modo compartilhado – o Thread B tenta adquirir o bloqueio SRW no modo exclusivo e esperas – o Thread A tenta adquirir o bloqueio SRW no modo compartilhado recursivamente. Isso será bem-sucedido desde que não haja nenhum garçom exclusivo (neste caso B). Como os bloqueios srw não têm fome de gravador, o thread A espera atrás do thread B. Agora, o Thread B está aguardando o Thread A, que, por sua vez, está aguardando o Thread B, causando uma espera circular e, portanto, um deadlock. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que o bloqueio SRW está sendo adquirido recursivamente.
• parâmetro dps2>< – para obter o rastreamento de pilha para a primeira aquisição.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - Endereço do primeiro rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: SRWLock
• Parar ID: RECURSIVE_ACQUIRE
• Parar código: 0x253
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O thread que está saindo ou sendo encerrado possui um bloqueio SRW.

Essa parada será gerada se o thread (Param2) que possui o bloqueio SRW (Param1) estiver saindo ou sendo encerrado. Isso resultará em um bloqueio SRW órfão e os threads que tentam adquirir esse bloqueio serão bloqueados indefinidamente. Para depurar sua parada:

• kb – para obter o rastreamento de pilha atual. É aí que o thread está saindo ou está sendo encerrado.
• parâmetro dps3<> – para obter o rastreamento de pilha de aquisição de bloqueio SRW.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - ThreadId do thread que está saindo ou sendo encerrado.
• Parâmetro 3 - Endereço do rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.
• Parâmetro 4 - Não usado

• Camada de teste: SRWLock
• Parar ID: EXIT_THREAD_OWNS_LOCK
• Parar código: 0x254
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O bloqueio SRW que está sendo liberado não foi adquirido por esse thread.

Essa parada será gerada se o bloqueio SRW (Param1) estiver sendo liberado pelo thread (Param2) que não adquiriu o bloqueio. Isso representa uma prática de programação incorreta que é difícil de acertar e pode levar a um comportamento imprevisível do aplicativo. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que o thread está liberando o bloqueio SRW que ele não adquiriu.
• parâmetro dps4>< – para obter o rastreamento de pilha de aquisição de bloqueio SRW.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - ThreadId atual.
• Parâmetro 3 - ThreadId do thread que adquiriu o bloqueio SRW.
• Parâmetro 4 - Endereço do rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.

• Camada de teste: SRWLock
• Parar ID: INVALID_OWNER
• Parar código: 0x255
• severidade : aviso de 
• erro único: 
• relatório de erro : Nenhum
• Log no arquivo: sim
• Criar backtrace: sim

A memória que está sendo liberada contém um bloqueio SRW ativo.

Essa parada será gerada se o endereço de memória (Param1) que está sendo liberado contiver um bloqueio SRW ativo que ainda está em uso. Isso pode resultar em um comportamento imprevisível do aplicativo, incluindo falhas e travamentos. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que a memória está sendo liberada que contém um bloqueio SRW ativo.
• parâmetro dps4>< – para obter o rastreamento de pilha de aquisição de bloqueio SRW.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - Endereço da memória que está sendo liberada.
• Parâmetro 3 - ThreadId do thread que adquiriu o bloqueio SRW.
• Parâmetro 4 - Endereço do rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.

• Camada de teste: SRWLock
• Parar ID: IN_FREED_MEMORY
• Parar código: 0x256
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

A DLL que está sendo descarregada contém um bloqueio SRW ativo.

Essa parada será gerada se a DLL que está sendo descarregada (Param2) contiver um bloqueio SRW ativo (Param1) que ainda está em uso. Isso pode resultar em um comportamento imprevisível do aplicativo, incluindo falhas e travamentos. Para depurar esta parada:

• kb – para obter o rastreamento de pilha atual. É aqui que a DLL está sendo descarregada que contém um bloqueio SRW ativo.
• du <parameter2> – para localizar o nome da DLL que está sendo descarregada.
• parâmetro dps4>< – para obter o rastreamento de pilha de aquisição de bloqueio SRW.

• Parâmetro 1 - BLOQUEIO SRW
• Parâmetro 2 - Endereço do nome da DLL que está sendo descarregada. Use o endereço< du >para ver o nome.
• Parâmetro 3 - ThreadId do thread que adquiriu o bloqueio SRW.
• Parâmetro 4 - Endereço do rastreamento de pilha de aquisição. Use o endereço< dps >para ver onde o bloqueio SRW foi adquirido.

• Camada de teste: SRWLock
• Parar ID: IN_UNLOADED_DLL
• Parar código: 0x257
• severidade : aviso de 
• erro único: 
• relatório de erro : Nenhum
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes da parada de memória

Liberação de bloco de memória virtual com tamanho inválido ou endereço inicial.

Essa parada será gerada se o verificador de aplicativo detectar um VirtualFree ou um descarregamento de DLL com um endereço inicial inválido ou o tamanho da alocação de memória. No caso de DLL descarregar, isso provavelmente significa uma corrupção de memória dentro da lista de DLL carregada. Para depurar essa parada, examine o rastreamento de pilha atual e o endereço de memória e o tamanho que está prestes a ser liberado e tente determinar por que eles são inválidos.

• Parâmetro 1 -Endereço base de  alocação.
• Parâmetro 2 - Tamanho da região da memória.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_FREEMEM
• Parar código: 0x600
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Chamada de alocação virtual incorreta.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada VirtualAlloc com um endereço inicial inválido ou tamanho da alocação de memória. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e o endereço de memória e o tamanho que está prestes a ser alocado e tente determinar por que eles são inválidos.

• Parâmetro 1 - Ponteiro para o endereço base de alocação.
• Parâmetro 2 - Ponteiro para o tamanho da região da memória.
• Parâmetro 3 - Não usado
• Parâmetro 4 - Não usado

• Camada de teste: Memória
• Parar ID: INVALID_ALLOCMEM
• Parar código: 0x601
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Chamada de exibição de mapa incorreta.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada MapViewOfFile com um endereço base ou tamanho inválido do mapeamento. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e o endereço de memória e o tamanho que está prestes a ser mapeado e tente determinar por que eles são inválidos.

• Parâmetro 1 - Ponteiro para o endereço base de mapeamento.
• Parâmetro 2 - Ponteiro para o tamanho da exibição.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_MAPVIEW
• Parar código: 0x602
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Sondando o endereço inválido.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada IsBadXXXPtr com um endereço inválido (por exemplo, um endereço no modo kernel, em vez de um endereço normal no modo de usuário) para que o buffer de memória seja investigado. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que o chamador da função IsBadXXXPtr acabou com um endereço inválido. Muitas vezes, o endereço é falso, por exemplo, um ponteiro não inicializado. A biblioteca MSDN lista alguns motivos pelos quais os aplicativos não devem usar as APIs IsBadXXXPtr: em um ambiente de multitarefa preemptiva, é possível que algum outro thread altere o acesso do processo à memória que está sendo testada. Desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Espera-se que os threads em um processo cooperem de tal forma que um não libere a memória que o outro precisa. O uso dessa função não nega a necessidade de fazer isso. Se isso não for feito, o aplicativo poderá falhar de maneira imprevisível. Devido a todos esses motivos, recomendamos nunca usar essas APIs.

• Parâmetro 1 - Endereço inicial.
• Parâmetro 2 -Tamanho do bloco de  memória.
• Parâmetro 3 - Endereço inválido.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: PROBE_INVALID_ADDRESS
• Parar código: 0x603
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Sondando memória livre.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada IsBadXXXPtr para uma alocação de memória gratuita. Isso é muito ruim porque é possível que, em alguns outros casos, essa memória já tenha sido reutilizado para alguma outra alocação. Como o caminho do código atual (kb) não possui essa memória, ele pode acabar corrompendo a memória de outra pessoa, com efeitos desastrosos. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que o chamador da função IsBadXXXPtr acabou sondando a memória livre. O endereço pode ser falso (por exemplo, ponteiro não inicializado) ou talvez já tenha liberado memória. Se a memória já tiver sido liberada por uma das APIs VirtualFree ou UnmapViewOfFile, '!avrf -vs -a parâmetro3' procurará um log de rastreamentos de pilha dos caminhos de código que alocaram/liberaram esse endereço e exibirão esses rastreamentos de pilha se estiverem disponíveis. Isso pode mostrar o rastreamento de pilha que liberou essa memória. Com mais frequência, a memória é uma alocação de heap já liberada. Para verificar essa possibilidade, '!avrf -hp -a parâmetro3' procurará um log de rastreamentos de pilha dos caminhos de código que alocaram/liberaram esse endereço de/para o heap e exibirão esses rastreamentos de pilha se eles estiverem disponíveis. A biblioteca MSDN lista alguns motivos pelos quais os aplicativos não devem usar as APIs IsBadXXXPtr: em um ambiente de multitarefa preemptiva, é possível que algum outro thread altere o acesso do processo à memória que está sendo testada. Desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Espera-se que os threads em um processo cooperem de tal forma que um não libere a memória que o outro precisa. O uso dessa função não nega a necessidade de fazer isso. Se isso não for feito, o aplicativo poderá falhar de maneira imprevisível. Devido a todos esses motivos, recomendamos nunca usar essas APIs.

• Parâmetro 1 - Endereço inicial.
• Parâmetro 2 -Tamanho do bloco de  memória.
• Parâmetro 3 - Endereço da página de memória gratuita.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: PROBE_FREE_MEM
• Parar código: 0x604
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Sondando uma página de proteção.

Essa parada será gerada se o verificador de aplicativos detectar uma chamada IsBadXXXPtr para uma alocação de memória que contenha pelo menos uma GUARD_PAGE. Isso é muito ruim porque é muito possível que esse GUARD_PAGE seja o fim da pilha atual de um thread. Conforme documentado na biblioteca MSDN: desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que o chamador da função IsBadXXXPtr acabou sondando um GUARD_PAGE. A biblioteca MSDN lista alguns motivos pelos quais os aplicativos não devem usar as APIs IsBadXXXPtr: em um ambiente de multitarefa preemptiva, é possível que algum outro thread altere o acesso do processo à memória que está sendo testada. Desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Espera-se que os threads em um processo cooperem de tal forma que um não libere a memória que o outro precisa. O uso dessa função não nega a necessidade de fazer isso. Se isso não for feito, o aplicativo poderá falhar de maneira imprevisível. Devido a todos esses motivos, recomendamos nunca usar essas APIs.

• Parâmetro 1 - Endereço inicial.
• Parâmetro 2 -Tamanho do bloco de  memória.
• Parâmetro 3 - Endereço da página de proteção.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: PROBE_GUARD_PAGE
• Parar código: 0x605
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Sondando o endereço NULL.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada IsBadXXXPtr com um endereço NULL. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que o chamador da função IsBadXXXPtr acabou com o endereço NULL. Normalmente, esse é o sinal de alguém que não está verificando o valor retornado de uma das funções de alocação de memória. Por exemplo, o código abaixo está incorreto:

void Use(PVOID p);

int main(void) {
    PVOID p;
    p = malloc(1024);
    Use(p);
    return 0;
}

void Use(PVOID p) {
    if (IsBadReadPtr(p)) {
        return;
    }
    // p is safe to be used here.
}

Esse código deve ser reescrito como este:

int main (void) 
{ 
    PVOID p; 
    
    p = malloc (1024); 
    if (NULL == p)) { 
        return -1;
     } 

    Use (p); 

    return 0; 
} 

void Use (PVOID p) 
{
    // 
    // p is safe to be used here. 
    // 
} 

A biblioteca MSDN lista alguns motivos pelos quais os aplicativos não devem usar as APIs IsBadXXXPtr: em um ambiente de multitarefa preemptiva, é possível que algum outro thread altere o acesso do processo à memória que está sendo testada. Desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Espera-se que os threads em um processo cooperem de tal forma que um não libere a memória que o outro precisa. O uso dessa função não nega a necessidade de fazer isso. Se isso não for feito, o aplicativo poderá falhar de maneira imprevisível. Devido a todos esses motivos, recomendamos nunca usar essas APIs.

• parâmetro 1 – Não usado.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: PROBE_NULL
• Parar código: 0x606
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Sondando o bloco de memória com o endereço inicial ou o tamanho inválido.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada IsBadXXXPtr com um endereço inicial inválido (por exemplo, um endereço no modo kernel, em vez de um endereço normal no modo de usuário) ou um tamanho inválido para que o buffer de memória seja investigado. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que o chamador da função IsBadXXXPtr acabou com um endereço ou tamanho inválido. Muitas vezes, o endereço ou o tamanho são falsos sem formatação, por exemplo, variáveis não inicializadas. A biblioteca MSDN lista alguns motivos pelos quais os aplicativos não devem usar as APIs IsBadXXXPtr: em um ambiente de multitarefa preemptiva, é possível que algum outro thread altere o acesso do processo à memória que está sendo testada. Desreferenciar ponteiros potencialmente inválidos pode desabilitar a expansão da pilha em outros threads. Um thread esgotando sua pilha, quando a expansão da pilha foi desabilitada, resulta no encerramento imediato do processo pai, sem nenhuma janela de erro pop-up ou informações de diagnóstico. Espera-se que os threads em um processo cooperem de tal forma que um não libere a memória que o outro precisa. O uso dessa função não nega a necessidade de fazer isso. Se isso não for feito, o aplicativo poderá falhar de maneira imprevisível. Devido a todos esses motivos, recomendamos nunca usar essas APIs.

• Parâmetro 1 - Endereço inicial.
• Parâmetro 2 -Tamanho do bloco de  memória.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: PROBE_INVALID_START_OR_SIZE
• Parar código: 0x607
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Descarregando a DLL com o tamanho inválido ou o endereço inicial.

Essa parada será gerada se o verificador de aplicativos detectar um descarregamento de DLL com um endereço inicial inválido ou tamanho do intervalo de memória DLL. Isso provavelmente significa uma corrupção de memória dentro da lista de DLL carregada ntdll.dll interna.

• Parâmetro 1 - Endereço base de memória DLL.
• Parâmetro 2 - Tamanho do intervalo de memória DLL.
• Parâmetro 3 - Endereço de nome DLL. Use du para despejá-lo.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_DLL_RANGE
• Parar código: 0x608
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Liberando o bloco de memória dentro do intervalo de endereços de pilha do thread atual.

Essa parada será gerada se o verificador de aplicativo detectar um VirtualFree para um bloco de memória que, na verdade, faz parte da pilha do thread atual (!). Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente entender por que a função chamada VirtualFree pensou que o bloco de memória foi alocado dinamicamente ou mapeado, mas que na verdade era memória alocada da pilha.

• Parâmetro 1 -Endereço base de  alocação.
• Parâmetro 2 - Tamanho da região da memória.
• Parâmetro 3 - Empilhar endereço de limite baixo.
• Parâmetro 4 - Empilhar endereço de limite alto.

• Camada de teste: Memória
• Parar ID: FREE_THREAD_STACK_MEMORY
• Parar código: 0x609
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Parâmetro FreeType incorreto para a operação VirtualFree.

Essa parada será gerada se o verificador de aplicativo detectar um VirtualFree com um valor incorreto para o parâmetro FreeType. Os dois únicos valores aceitáveis para esse parâmetro são MEM_DECOMMIT e MEM_RELEASE. Se VirtualFree for chamado com qualquer outro valor, exceto esses dois, VirtualFree falhará ao liberar a memória. Para depurar essa parada, examine o rastreamento de pilha atual (kb): o chamador do VirtualFree provavelmente é o culpado.

• Parâmetro 1 - Valor incorreto usado pelo aplicativo.
• Parâmetro 2 - Valor correto esperado 1.
• Parâmetro 3 - Valor correto esperado 2.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_FREE_TYPE
• Parar código: 0x60A
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Tentando liberar o bloco de memória virtual que já está gratuito.

Essa parada será gerada se o verificador de aplicativos detectar um VirtualFree para um endereço que já esteja gratuito. Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente determinar por que a memória já está livre, mas o aplicativo está tentando liberá-la novamente. '!avrf -vs -a parameter1' procurará um log de rastreamentos de pilha dos caminhos de código que alocaram/liberaram esse endereço e exibirão esses rastreamentos de pilha se estiverem disponíveis. Isso pode mostrar o rastreamento de pilha que liberou essa memória.

• Parâmetro 1 - Endereço do bloco de memória.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: MEM_ALREADY_FREE
• Parar código: 0x60B
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Parâmetro De tamanho incorreto para a operação VirtualFree (MEM_RELEASE).

Essa parada será gerada se o verificador de aplicativo detectar um VirtualFree (MEM_RELEASE) com um valor diferente de zero para o parâmetro dwSize. Ao usar MEM_RELEASE, o único valor aceitável para esse parâmetro é 0. Se VirtualFree for chamado com qualquer outro valor, exceto 0, VirtualFree falhará ao liberar a memória. Para depurar essa parada, examine o rastreamento de pilha atual (kb): o chamador do VirtualFree provavelmente é o culpado.

• Parâmetro 1 - Tamanho incorreto usado pelo aplicativo.
• Parâmetro 2 - Tamanho correto esperado (0).
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_FREE_SIZE
• Parar código: 0x60C
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada gerada na rotina do ponto de entrada de DLL.

Essa parada será gerada se a função DllMain (ponto de entrada) de uma DLL estiver gerando uma exceção. Um exemplo de por que isso é ruim é: se DllMain(DLL_PROCESS_ATTACH) estiver criando uma exceção, o carregador de DLL do Windows irá: – Capturar e ocultar a exceção; - Descarregue a DLL sem chamar seu DllMain(DLL_PROCESS_DETACH). Portanto, em muitos casos, a DLL já alocou alguns recursos e, em seguida, levantou a exceção e não terá a chance de liberar esses recursos no DllMain (DLL_PROCESS_DETACH). Para depurar esta parada:

• Parâmetro 1 - Nome da DLL (use du para despejá-lo).
• Parâmetro 2 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 3 - Registro de contexto. Use .cxr para exibi-lo.
• Parâmetro 4 - Verificador descritor dll

• Camada de teste: Memória
• Parar ID: DLL_UNEXPECTED_EXCEPTION
• Parar código: 0x60D
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada gerada na função thread.

Essa parada será gerada se uma função de thread estiver gerando uma exceção. Isso é ruim porque todo o processo será morto. Para depurar esta parada:

• < parameter1> pode ser significativo para o tipo de exceção. Por exemplo, um código de exceção C0000005 significa Violação de Acesso.
• Parâmetro .exr2>< – para exibir as informações de exceção.
• Parâmetro .cxr3 <> seguido por kb – para exibir as informações de contexto de exceção

• Parâmetro 1 -Código de  exceção.
• Parâmetro 2 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 3 - Registro de contexto. Use .cxr para exibi-lo.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: THREAD_UNEXPECTED_EXCEPTION
• Parar código: 0x60E
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada gerada durante a investigação da memória.

Essa parada será gerada se tivermos uma exceção durante uma chamada IsBadXXXPtr. Isso significa que o buffer de memória que estamos investigando não tem realmente a proteção assumida pelo chamador ou que a memória já foi liberada, etc. Consulte a discussão acima sobre outro código de parada (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE) para obter mais exemplos de por que não é recomendável usar as APIs IsBadXXXPtr. Para depurar esta parada:

• < parameter1> normalmente será C0000005, uma Violação de Acesso
• Parâmetro .exr2>< – para exibir as informações de exceção
• Parâmetro .cxr3 <> seguido por kb – para exibir as informações de contexto de exceção e o rastreamento de pilha no momento em que a exceção foi gerada

• Parâmetro 1 -Código de  exceção.
• Parâmetro 2 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 3 - Registro de contexto. Use .cxr para exibi-lo.
• Parâmetro 4 - Não usado

• Camada de teste: Memória
• Parar ID: PROBE_UNEXPECTED_EXCEPTION
• Parar código: 0x60F
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Tentando redefinir o endereço NULL.

Essa parada será gerada se o verificador de aplicativo detectar uma chamada VirtualFree (MEM_RESET) com um primeiro parâmetro NULL. MEM_RESET deve ser usado apenas para memória já alocada, portanto, NULL não é um primeiro parâmetro válido nesse caso.

• parâmetro 1 – Não usado.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_MEM_RESET
• Parar código: 0x610
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Liberando o bloco de memória de heap dentro do intervalo de endereços de pilha do thread atual.

Essa parada será gerada se o verificador de aplicativos detectar um HeapFree para um bloco de memória que, na verdade, faz parte da pilha do thread atual (!). Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente entender por que a função chamada HeapFree pensou que o bloco de memória foi alocado dinamicamente ou mapeado, mas que na verdade era memória alocada da pilha.

• Parâmetro 1 -Endereço base de  alocação.
• Parâmetro 2 - Tamanho da região da memória.
• Parâmetro 3 - Empilhar endereço de limite baixo.
• Parâmetro 4 - Empilhar endereço de limite alto.

• Camada de teste: Memória
• Parar ID: FREE_THREAD_STACK_MEMORY_AS_HEAP
• Parar código: 0x612
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Desmapear a região de memória dentro do intervalo de endereços de pilha do thread atual.

Essa parada será gerada se o verificador de aplicativo detectar um UnmapViewOfFile para um bloco de memória que, na verdade, faz parte da pilha do thread atual (!). Para depurar essa parada, examine o rastreamento de pilha atual (kb) e tente entender por que a função chamada UnmapViewOfFile pensou que o bloco de memória foi alocado dinamicamente ou mapeado, mas que na verdade era a memória alocada da pilha.

• Parâmetro 1 -Endereço base de  alocação.
• Parâmetro 2 - Tamanho da região da memória.
• Parâmetro 3 - Empilhar endereço de limite baixo.
• Parâmetro 4 - Empilhar endereço de limite alto.

• Camada de teste: Memória
• Parar ID: FREE_THREAD_STACK_MEMORY_AS_MAP
• Parar código: 0x613
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Endereço de RTL_RESOURCE incorreto.

Essa parada será gerada se o aplicativo estiver tentando usar NULL ou algum outro endereço incorreto (por exemplo, um endereço no modo kernel) como o endereço de um objeto válido. RtlInitializeResource (NULL) é uma chamada de API incorreta que disparará esse tipo de parada de verificador. *Parameter1* é o endereço incorreto usado e o culpado está no rastreamento de pilha (exiba-o com kb).

• Parâmetro 1 - Endereço.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_RESOURCE_ADDRESS
• Parar código: 0x614
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Endereço de seção crítico inválido.

Essa parada será gerada se o aplicativo estiver tentando usar NULL ou algum outro endereço incorreto (por exemplo, um endereço no modo kernel) como o endereço de um objeto válido. EnterCriticalSection(NULL) é uma chamada de API incorreta que disparará esse tipo de parada de verificador. *Parameter1* é o endereço incorreto usado e o culpado está no rastreamento de pilha (exiba-o com kb).

• Parâmetro 1 - Endereço.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_CRITSECT_ADDRESS
• Parar código: 0x615
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Tente executar o código na memória não executável.

Essa parada será gerada se o aplicativo estiver tentando executar o código de um endereço que não seja executável ou gratuito. Para depurar esta parada:

• u <parameter2> – para desmontar o código culpado
• Parâmetro .exr3>< – para exibir as informações de exceção
• Parâmetro .cxr4 <> seguido por kb – para exibir as informações de contexto de exceção e o rastreamento de pilha para o momento em que a exceção foi gerada.

• Parâmetro 1 - Endereço que está sendo acessado.
• Parâmetro 2 - Código executando acesso inválido.
• Parâmetro 3 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 4 - Registro de contexto. Use .cxr para exibi-lo.

• Camada de teste: Memória
• Parar ID: THREAD_UNEXPECTED_EXCEPTION_CODE
• Parar código: 0x616
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada gerada ao inicializar o buffer de saída.

Essa parada será gerada se tivermos uma exceção ao inicializar um buffer especificado como parâmetro de saída para uma API Win32 ou CRT. Isso normalmente significa que o tamanho do buffer de saída especificado está incorreto. Para depurar esta parada:

• Parâmetro .exr3>< – para exibir as informações de exceção.
• Parâmetro .cxr4 <> seguido de kb – para exibir as informações de contexto de exceção e o rastreamento de pilha no momento em que a exceção foi gerada.

• Parâmetro 1 - Endereço inicial do buffer.
• Parâmetro 2 - Tamanho do buffer.
• Parâmetro 3 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 4 - Registro de contexto. Use .cxr para exibi-lo.

• Camada de teste: Memória
• Parar ID: OUTBUFF_UNEXPECTED_EXCEPTION
• Parar código: 0x617
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Exceção inesperada ao tentar localizar o tamanho do bloco de heap.

Essa parada será gerada se tivermos uma exceção ao chamar o HeapSize para um bloco de heap que está sendo liberado. Isso normalmente significa que o endereço de bloco de heap especificado está incorreto ou o heap está corrompido. Para depurar esta parada:

• Parâmetro .exr3>< – para exibir o registro de exceção.
• Parâmetro .cxr4 <> seguido de kb – para exibir as informações de contexto de exceção e o rastreamento de pilha no momento em que a exceção foi gerada.

• Parâmetro 1 - Endereço do bloco de heap que está sendo liberado.
• Parâmetro 2 - Identificador de heap.
• Parâmetro 3 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 4 - Registro de contexto. Use .cxr para exibi-lo.

• Camada de teste: Memória
• Parar ID: SIZE_HEAP_UNEXPECTED_EXCEPTION
• Parar código: 0x618
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Liberação de bloco de memória com endereço inicial inválido.

Essa parada será gerada se o programa chamar VirtualFree (MEM_RELEASE) com um parâmetro lpAddress que não é o endereço base retornado pela função VirtualAlloc ou VirtualAllocEx quando a região das páginas foi reservada; Para depurar esta parada:

• kb – para exibir o rastreamento de pilha atual, que está chamando VirtualFree. O provável culpado é a DLL que chama VirtualFree.

• Parâmetro 1 - Endereço do bloco de memória que está sendo liberado.
• Parâmetro 2 - Endereço  de bloco de memória correto esperado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_FREEMEM_START_ADDRESS
• Parar código: 0x619
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Bloco de memória não mapeado com endereço inicial inválido.

Essa parada será gerada se o programa chamar UnmapViewOfFile com um parâmetro lpBaseAddress que não seja idêntico ao valor retornado por uma chamada anterior para a função MapViewOfFile ou MapViewOfFileEx. Para depurar esta parada:

• kb – para exibir o rastreamento de pilha atual, que está chamando UnmapViewOfFile. O provável culpado é a DLL que chama UnmapViewOfFile.

• Parâmetro 1 - Endereço do bloco de memória sendo não mapeado.
• Parâmetro 2 - Endereço  de bloco de memória correto esperado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: INVALID_UNMAPVIEW_START_ADDRESS
• Parar código: 0x619
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

exceção inesperada gerada na função de retorno de chamada do threadpool.

Essa parada será gerada se uma função de retorno de chamada no thread de threadpool estiver gerando uma exceção. Para depurar esta parada:

• < parameter1> pode ser significativo para o tipo de exceção. Por exemplo, um código de exceção C0000005 significa Violação de Acesso.
• Parâmetro .exr2>< – para exibir as informações de exceção.
• Parâmetro .cxr3 <> seguido por kb – para exibir as informações de contexto de exceção.

• Parâmetro 1 -Código de  exceção
• Parâmetro 2 -Registro de  exceção. Use .exr para exibi-lo
• Parâmetro 3 - Registro de contexto. Use .cxr para exibi-lo
• Parâmetro 4 - Não usado

• Camada de teste: Memória
• Parar ID: THREADPOOL_UNEXPECTED_EXCEPTION
• Parar código: 0x61B
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

código na memória não executável

Essa parada será gerada se o aplicativo estiver tentando executar o código de um endereço que não seja executável ou gratuito. Para depurar esta parada:

• u <parameter2> – para desmontar o código culpado
• Parâmetro .exr3>< – para exibir as informações de exceção
• Parâmetro .cxr4 <> seguido por kb – para exibir as informações de contexto de exceção e o rastreamento de pilha para o momento em que a exceção foi gerada.

• Parâmetro 1 - Endereço que está sendo acessado
• Parâmetro 2 - Código executando acesso inválido
• Parâmetro 3 -Registro de  exceção. Use .exr para exibi-lo.
• Parâmetro 4 - Registro de contexto. Use .cxr para exibi-lo.

• Camada de teste: Memória
• Parar ID: THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Parar código: 0x61C
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Criando heap executável.

Essa parada será gerada se o aplicativo estiver criando um heap executável. Isso pode ser um risco à segurança.

• parâmetro 1 – Não usado.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: EXECUTABLE_HEAP
• Parar código: 0x1D
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Alocando memória executável.

Essa parada será gerada se o aplicativo estiver alocando memória executável. Isso pode ser um risco à segurança.

• Parâmetro 1 - Proteção de página especificada pelo chamador.
• parâmetro 2 – Não usado.
• parâmetro 3 – Não usado.
• parâmetro 4 – Não usado.

• Camada de teste: Memória
• Parar ID: EXECUTABLE_MEMORY
• Parar código: 0x1E
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes de interrupção de TLS

Descarregando a DLL que alocava o índice TLS que não foi liberado.

Essa parada será gerada se uma DLL que alocou um índice TLS estiver sendo descarregada antes de liberar esse índice TLS. Para depurar esta parada:

• du <parameter3> – exibir o nome da DLL culpada
• .reload xxx.dll=<parameter4> – recarregar símbolos para a DLL culpada (se necessário). xxx.dll é o nome da DLL exibida na etapa acima.
• u <parameter2> – desmonte o código que alocou o TLS. Isso deve apontar para a função que alocou o TLS, mas esqueceu de liberá-lo antes que a DLL fosse descarregada.

• Parâmetro 1 - Índice TLS
• Parâmetro 2 - Endereço do código que alocou esse índice TLS.
• Parâmetro 3 - Endereço de nome DLL. Use du para despejá-lo.
• Parâmetro 4 - Endereço base da DLL.

• Camada de teste: TLS
• Parar ID: TLS_LEAK
• Parar código: 0x350
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Estrutura TLS do verificador corrompido.

Essa parada será gerada se as estruturas internas do verificador usadas para armazenar o estado dos slots TLS para thread estiverem corrompidas. Muito provavelmente isso é devido a alguma corrupção aleatória no processo.

• Parâmetro 1 - Endereço TEB.
• Parâmetro 2 -Endereço  TEB esperado.
• Parâmetro 3 - ID do thread.
• Parâmetro 4 - ID de thread esperada.

• Camada de teste: TLS
• Parar ID: CORRUPTED_TLS
• Parar código: 0x351
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Usando um índice TLS inválido.

Essa parada será gerada se um índice TLS inválido for usado. Na maioria dos casos, é porque o código ainda está usando esse índice quando TlsFree é chamado. Aqui está um exemplo para o thread do thread.

• T1: cargas de Dll e TlsAlloc
• T1: Retorno de chamada de fila
• T1: Retorno de chamada esperado/cancelado ignorado
• T1: TlsFree
• T2: O retorno de chamada executa e chama TlsSetValue
• T1: descarregamentos de Dll

• Parâmetro 1 - Índice TLS
• Parâmetro 2 - Não usado.
• Parâmetro 3 - Não usado.
• Parâmetro 4 - Não usado.

• Camada de teste: TLS
• Parar ID: INVALID_TLS_INDEX
• Parar código: 0x352
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Detalhes da parada do Threadpool

A prioridade desse thread do thread do threadpool foi alterada.

Essa parada será gerada se a prioridade do thread for alterada quando ela for retornada para o threadpool.

• Formato: –  thread do thread do threadpool (%x) tendo executado o Retorno de Chamada (%p) tem uma prioridade de thread alterada (%i -> %i)
• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 -  Prioridade atual.

• Camada de teste: Threadpool
• Parar ID: INCONSISTENT_PRIORITY
• Parar código: 0x700
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

A afinidade desse thread do thread de threadpool foi alterada.

Essa parada será gerada se a afinidade de thread for alterada quando ela for retornada para o threadpool.

• Formato: - thread de thread de threadpool (%x) tendo executado o Retorno de Chamada (%p) tem uma máscara de afinidade de thread alterada (%p -> %p)
• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Afinidade atual.

• Camada de teste: Threadpool
• Parar ID: INCONSISTENT_AFFINITY_MASK
• Parar código: 0x701
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Msg não processado no pool msg do thread atual.

Essa parada será gerada se qualquer mensagem deixada como não processada quando esse thread do thread do threadpool for retornado ao pool. É perigoso, pois será processado em um contexto totalmente diferente. Use !avrf -tp <Param4> para ver as mensagens postadas neste thread.

• Formato: - thread de thread de threadpool (%x) tendo executado o Retorno de Chamada (%p) tem uma mensagem de janela pendente (%x: %x)
• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - ID do thread do Threadpool. Use !avrf -tp <threadid> para ver as mensagens postadas neste thread.

• Camada de teste: Threadpool
• Parar ID: ORPHANED_THREAD_MESSAGE
• Parar código: 0x702
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

A janela não fechada pertencia ao thread atual.

Essa parada será gerada se qualquer janela for mantida ativa quando esse thread do thread do threadpool for retornado para o pool.

• Formato: -  thread do thread do thread de threadpool (%x) que executou o Retorno de Chamada (%p) tem hwnd válido (%x: %s) que pode receber mensagens
• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - ID do thread do Threadpool.

• Camada de teste: Threadpool
• Parar ID: ORPHANED_THREAD_WINDOW
• Parar código: 0x703
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

ExitThread() ou TerminateThread() em um thread de thread de threadpool.

Essa parada será gerada se ExitThread for chamado em um thread de threadpool. É proibido, pois tornará o sistema instável. Isso causará vazamento de recursos, congelamento ou AV.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: ILLEGAL_THREAD_TERMINATION
• Parar código: 0x704
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O thread está no estado de representação quando é retornado para um thread de threadpool.

Essa parada será gerada se a função de retorno de chamada alterar o token de thread para representar outro usuário e esquecer de redefini-lo antes de retorná-lo para o threadpool.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: THREAD_IN_IMPERSONATION
• Parar código: 0x705
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Uma função que requer thread persistente é chamada.

Algumas APIs do Microsoft Windows precisam ser chamadas dentro de um thread dedicado ou persistente. No threadpool, você geralmente deve evitar o uso do armazenamento local do thread e a enfileiramento de chamadas assíncronas que exigem um thread persistente, como a função RegNotifyChangeKeyValue. No entanto, essas funções podem ser enfileiradas em um thread de trabalho persistente usando QueueUserWorkItem com a opção WT_EXECUTEINPERSISTENTTHREAD. Um kb no depurador revelará o chamador.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: PERSISTED_THREAD_NEEDED
• Parar código: 0x706
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O thread está no estado de transação sujo.

Essa parada será gerada se a função de voltar de chamada esquecer de fechar ou redefinir o identificador de transação atual.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Identificador de transação.

• Camada de teste: Threadpool
• Parar ID: DIRTY_TRANSACTION_CONTEXT
• Parar código: 0x707
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Esse estado de threadpool tem chamadas CoInit e CoUnInit desbalanceadas.

Essa parada será gerada se a função de chamada de volta chamar CoInit e CoUnInit desbalanceadas.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Contagens de chamadas balanceadas.

• Camada de teste: Threadpool
• Parar ID: DIRTY_COM_STATE
• Parar código: 0x708
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Os parâmetros do objeto de temporizador são inconsistentes. O período deve ser 0 quando WT_EXECUTEONLYONCE é especificado ao criar o temporizador

Essa parada será gerada se o período para sinalizar o temporizador não for zero quando o temporizador estiver definido para sinalizar apenas uma vez com o sinalizador WT_EXECUTEONLYONCE

• Parâmetro 1 - Período especificado.
• Parâmetro 2 - Sinalizadores especificados.
• Parâmetro 3 - Não usado.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: INCONSISTENT_TIMER_PARAMS
• Parar código: 0x709
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O bloqueio do carregador foi mantido pelo thread do thread do threadpool dentro do retorno de chamada.

Essa parada será gerada se o bloqueio do carregador for mantido dentro do retorno de chamada e não for liberado quando o thread for retornado para o threadpool.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: LOADER_LOCK_HELD
• Parar código: 0x7A
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

O idioma preferencial é definido pelo thread do thread do thread dentro do retorno de chamada.

Essa parada será gerada se o idioma preferencial estiver definido dentro do retorno de chamada e não for limpo quando o thread for retornado para o threadpool.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: PREFERRED_LANGUAGES_SET
• Parar código: 0x7B
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

A prioridade em segundo plano é definida pelo thread do thread do threadpool dentro do retorno de chamada.

Essa parada será gerada se a prioridade em segundo plano estiver definida dentro do retorno de chamada e não estiver desabilitada quando o thread for retornado para o threadpool.

• Parâmetro 1 -Função de  retorno de chamada.
• Parâmetro 2 - Contexto.
• Parâmetro 3 - Rastreamento de pilha de alocação de objeto threadpool, use dps para despejá-lo.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: BACKGROUND_PRIORITY_SET
• Parar código: 0x7C
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

TerminateThread() em um thread do thread do threadpool.

Essa parada será gerada se TerminateThread for chamado em um thread de threadpool. É proibido, pois tornará o sistema instável. Isso causará vazamento de recursos, congelamento ou AV.

• Parâmetro 1 - Não usado.
• Parâmetro 2 - Não usado.
• Parâmetro 3 - Não usado.
• Parâmetro 4 - Não usado.

• Camada de teste: Threadpool
• Parar ID: ILLEGAL_THREAD_TERMINATION
• Parar código: 0x7D
• severidade do : erro de 
• erro único: 
• relatório de erro : interrupção do 
• Log no arquivo: sim
• Criar backtrace: sim

Consulte Também

Verificador de Aplicativos – Parar códigos e definições

Verificador de Aplicativos – Visão geral

Verificador de Aplicativos – Recursos

Verificador de Aplicativos – Testando aplicativos

Verificador de Aplicativos – Testes no Verificador de Aplicativos

Verificador de Aplicativos – Depuração do Verificador de Aplicativos para

Verificador de Aplicativos – Perguntas frequentes