Tag Archives: bsod

BSOD

Existem cenários que você precisa entender o que está acontecendo no ambiente, na sua aplicação, no SO, reiniciar a máquina e perder o que está acontecendo não é uma opção.

Se a aplicação é consistente na geração de Logs, ou o Windows consegue manter os logs de um problema enquanto a maquina está “travada” já ajuda consideravelmente, mas existem cenários que infelizmente tudo para de uma tal forma que infelizmente só um reboot salva, mas vc vai perder a rastreabilidade do problema.

Para situações como essa, alguns servidores possuem bem próximo ao botão de liga/desliga um outro botão de interrupção do SO onde força o despejo de memória através de uma Tela Azul da Morte para o arquivo de dump para uma análise posterior do ocorrido (verificar o manual do seu fabricante).

Para outros cenários, principalmente quando você não tem acesso ao servidor físico, existe a opção de adicionar duas chaves de registro que vão gerar esse BSOD no seu Windows (Cliente ou Servidor).

Windows Registry Editor Version 5.00

; For PS/2 keyboards
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"CrashOnCtrlScroll"=dword:00000001

; For USB keyoards
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters]
"CrashOnCtrlScroll"=dword:00000001

Adicionadas estas chaves, reinicie o seu Windows.

Pressionando CTRL + 2x Scroll Lock o Windows vai iniciar o processo da Tela Azul.

Atenção !!!

Existem outras configurações necessárias para que isso funcione direito e você tenha o que analisar !

  1. Espaço em disco (Normalmente ninguém se preocupa onde está o Page File nem mesmo a configuração do Dump)
  2. Configuração do Dump (Se você nunca mexeu ele é Full RAM e vai gerar o arquivo na unidade C)
  3. Mais espaço em Disco (A geração do arquivo de Dump vem com a memória RAM e o conteúdo do PF, no final do processo o Windows gera um PF novo)
  4. Tempo (é totalmente variável já que trata-se de toda a memória da maquina sendo armazenada em um arquivo, quanto mais RAM usada maior é o arquivo)

Se você conseguir gerar um dump bem sucedido, vai conseguiu analisar com o WinDBG.

Boa Sorte.

Liberar toda a memória do servidor

Todos sabemos que o SQL é um consumidor de memória frenético, quanto mais memória disponível mais memória ele vai reservar para ele.

O que é um desenho “by default”, ele sempre fará isso afinal de contas ele precisa alocar as páginas de dados do seu banco em algum lugar.

Para resolver todos os seus problemas, existe uma forma de liberar toda a memória disponível de uma só vez do seu servidor e não é parando o serviço do SQL.

Para isso, você vai precisar o Visual Studio instalado, vamos criar um novo projeto dele…

Importante! Abra o Visual Studio como administrador !

Novo projeto de linha de comando

Escreva o nome que quiser para o app

Copie e cole o código abaixo no projeto:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

public class CriticalProcess
{
    [DllImport("ntdll.dll", SetLastError = true)]
    private static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);

    static void Main(string[] args)
    {
        int isCritical = 1;  // queremos que ele seja um processo crítico
        int BreakOnTermination = 0x1D;  // valor para BreakOnTermination (flag)

        Process.EnterDebugMode();  //acquire Debug Privileges

        // configurando o BreakOnTermination = 1 para o processo ativo
        NtSetInformationProcess(Process.GetCurrentProcess().Handle, BreakOnTermination, ref isCritical, sizeof(int));
    }
}

Se tudo ocorrer como esperado, dependendo da quantidade de memória do seu servidor isso pode demorar de alguns segundos a algumas horas.

Por mais que tenhamos criado uma aplicação de linha de comando a primeira parte do processo é bem gráfica e todos já tiveram o grande prazer de conhecer:

Ele vai gerar um DUMP de toda a memória para o arquivo de paginação e depois que a maquina reiniciar ele vai copiar esse arquivo de paginação para um arquivo chamado memory.dump

É só isso,,, execução e queda,,,

Agora falando sério: NUNCA !!!! JAMAIS !!!!! Simplesmente pegue o código de qualquer coisa que você encontra na internet e saia executando sem antes entender o que ele faz.

Esse exemplo é bem ridículo, mas imagina um script que você leu o por alto achando que vai resolver todos os seus problemas de backup, ou de fragmentação de índice e descobre que no meio tem um sp_msforeach_table com um sp_msforeach_db que trunca as tabelas, ou pior, alguém cria uma chave de criptografia e habilita TDE nas suas bases e depois força a remoção da chave,,,, a culpa é tão e somente sua! Você é o DBA é sua responsabilidade preservar os dados.

Tenha discernimento com o que você copia da internet e de onde copia essas informações.

SEMPRE LEIA e NUNCA EXECUTE DIRETAMENTE EM PRODUÇÃO !!!