Blog

No último post, em resposta à uma dúvida de um leitor, comentei um pouco sobre como criar e usar novas IOCTLs. Afinal de contas, o lema desse blog é “Servir bem para servir sempre”. Dúvidas de leitores são ótimas fontes de sugestões para novos posts. Creio que como em qualquer outra especialidade, o desenvolvimento de drivers é um tópico que pode ser desmembrado em muitas e muitas partes. Não é a toa que o menor livro que eu conheço sobre desenvolvimento de drivers não tenha menos de quatrocentas páginas. Por isso é bom saber quais são as dificuldades dos leitores para saber sobre qual assunto postar aqui. Sintam-se à vontade para mandar novas sugestões ou dúvidas. Já há algum tempo, recebi um e-mail de Fábio Dias (Fortaleza, CE), que sugeriu um post sobre como acessar o Registry a partir de um driver. Muito bem, vamos lá.

HKEY_LOCAL_MACHINE é coisa se User Mode

Antes de sair dizendo quais APIs você deve usar para acessar o registro, vamos antes dar uma olhada em como o registro está organizado. Creio que o primeiro passo aqui seja falar sobre como abrir uma chave do registro. Assim como em User Mode, temos que ter uma string que informe o caminho da chave a qual queremos abrir, e assim obter um handle para ela. Opa! Eu disse handle? Sendo assim, vale comentar que as chaves do registro também são recursos gerenciados pelo Object Manager. As chaves do registro estão todas armazenadas sob o namespace “\Registry”. Desta forma, enquanto usamos HKEY_LOCAL_MACHINE em User Mode como nome de uma das divisões básicas do registro, em Kernel Mode usamos “\Registry\Machine”. E de maneira análoga à HKEY_USERS temos “\Registry\Users”. Mais detalhes aqui.

Qual é o CurrentControlSet?

A rotina DriverEntry de qualquer driver para Windows NT recebe dois parâmetros de entrada, sendo um deles um ponteiro para a estrutura DRIVER_OBJECT que representa a instância do nosso driver, e o outro parâmetro é um UNICODE_STRING contendo o caminho do registro que indica onde nosso driver está cadastrado. Mas como assim? Nosso driver pode não saber como ele foi cadastrado no registro? Aqui na referência é simples:

Tudo bem, vamos pegar carona em um driver qualquer e dar uma olhada nisso utilizando o WinDbg. Vamos abrir um parênteses aqui para informar aos mais novos neste blog que estou utilizando uma máquina virtual para fazer os testes com o driver de exemplo, como explica neste post. Isso permite que eu possa fazer Debug de Kernel sem necessariamente ter que utilizar duas máquinas. Para facilitar a substituição do driver a cada modificação que faço, estou utilizando o mapeamento de drivers do WinDbg, como explica neste outro post. Este recurso permite que o WinDbg sempre carregue uma nova versão driver na máquina TARGET sem que eu tenha que necessariamente substituir o driver nela. Fecha parênteses.

Antes mesmo do driver ser carregado, coloquei um breakpoint na rotina DriverEntry. Opa! Como você pode colocar um breakpoint em um driver que ainda não foi carregado? Ah tá… Você pode fazer isso utilizando o comando bu como mostra abaixo. Os breakpoints são setados quando o driver for carregado. Na linha seguinte, eu apenas listo os breakpoints, só pra… Quando o driver é carregado, a execução pára em meu breakpoint e uso a extensão !ustr, que mostra UNICODE_STRINGs, para ver o valor desse meu segundo parâmetro da DriverEntry.

kd> bu KernelReg!DriverEntry

kd> bl

 0 eu             0001 (0001) (KernelReg!DriverEntry)

kd> g

KD: Accessing 'Z:\Sources\DriverEntry\KernelReg\objchk_w2k_x86\i386\KernelReg.sys'

    (\??\C:\WINDOWS\system32\drivers\KernelReg.sys)

  File size 2K.

MmLoadSystemImage: Pulled \??\C:\WINDOWS\system32\drivers\KernelReg.sys from kd

Breakpoint 0 hit

KernelReg!DriverEntry:

f8d394a0 8bff            mov     edi,edi

kd> !ustr poi(pusRegistryPath)

String(114,114) at 82302000: \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\KernelReg

Mas não era pra ser CurrentControlSet? Na verdade o CurrentControlSet é um link para um outro ControlSet. No caso observado acima, o CurrentControlSet está refletindo o ControlSet001, ou seja, as alterações feitas no ControlSet001 são vistas no CurrentControlSet e vice-versa. O CurrentControlSet pode refletir qualquer outro ControlSet. Algumas regras determinam quando eles mudam, como em casos de mudanças de configurações de sistema ou instalações de drivers. Para saber para onde o CurrentControlSet está apontando, dê uma olhada no valor Current que está na chave “\Registry\Machine\System\Select” como mostra a figura abaixo.

Mas isso é apenas para efeito de curiosidade. Quando você utiliza CurrentControlSet como parte do caminho da chave que você deseja acessar, o Object Manager faz a traducão pra você e todos vivem felizes para sempre.

Cadê \Registry\Machine\Software?

Já pode ter acontecido com alguns de vocês. Vocês escrevem um driver que deve ler uma certa chave dentro de “\Registry\Machine\Software” quando o driver é carregado. Enquanto você faz testes com o driver, que neste momento tem seu Start configurado para Manual(3), tudo funciona que é uma maravilha, mas na hora de mudar o Start do driver para Boot(0) ou System(1), não conseguimos abrir a chave recebendo STATUS_OBJECT_NAME_NOT_FOUND (0xC00000034).

Como assim nome não encontrado? Estava aqui agora mesmo! O que acontece é que a chave SOFTWARE é montada mais tarde. Assim, durante o boot do sistema ela ainda não existe. Para fazer acesso a essa chave, você terá que esperar um cadim, talvez utilizando a tática deste post. Aí tudo funciona que é uma beless.

Algo a dizer sobre HKEY_CURRENT_USER?

Então, veja bem. Quem é o Current User? Usuário que está fazendo a chamada, certo? Assim, conforme a tradição, você começa pensando que é fácil e estando logado como Paulo, você inicia seu driver manualmente. O driver, durante a chamada à DriverEntry, lê configurações referentes ao usuário logado, que de fato estão armazenadas dentro de HKEY_CURRENT_USER do Paulo. Bom, acho que está certo até aqui. Já ouviram aquela expressão “Quem muito acha acaba se perdendo”? Pois é, tá tudo errado. Para Paulo, as configurações estão lá mesmo, mas a rotina DriverEntry é chamada em contexto de sistema, que por sinal não é Paulo.

Esse é um problema enfrentado mesmo em User Mode, quando serviços, que são executados em conta de sistema, tentam abrir a chave HKEY_CURRENT_USER. Uma coisa que temos que ter em mente é que “O usuário logado” não é uma informação única do sistema. Tentem imaginar um Terminal Service, podem haver vários usuários logados ao mesmo tempo. Mesmo quando há somente um usuário logado no sistema, threads podem ser executadas em contexto de outros usuários ou mesmo em contexto de sistema. Drivers não tem contexto próprio. Algumas partes do driver são executadas em contexto de sistema, outras em contexto arbitrário. Dependendo do tipo de driver e sua posiçao dentro da pilha de dispositivos, ele pode receber as chamadas em contexto do usuário. Que é o caso dos drivers de File System por exemplo.

Ah tá! Aí sim HKEY_CURRENT_USER vai funcionar! Er… Como posso dizer isso? Não, não vai funcionar. Segundo a referência da Microsoft, não existe uma tradução simples para HKEY_CURRENT_USER, mas existem rotinas que oferecem simplificações. Depois de toda essa conversinha sobre contexto e tals, você ainda terá que acessar a chave HKEY_USERS, ou melhor dizendo, “\Registry\User”, no formato já conhecido dos programadores User Mode utilizado com HKEY_USERS. Um exemplo é: “\Registry\User\S-1-5-21-73586283-1897051121-839522115-500”. O equivalente para uma conta de sistema é a chave “\Registry\User\.DEFAULT”.

Tá tá tá! Exemplo agora

Mais uma vez, estou assumindo que você já sabe compilar e instalar um driver como explicado neste post. O código exemplo disponível para download ao final deste post também pode ser compilado pelo Visual Studio utilizando o DDKBUILD, como explica este post. Neste exemplo vou mostrar a leitura de dois valores do registro que estão em uma chave como mostra a figura abaixo. Para deixar a brincadeira mais divertida, quando o driver for executado pela primeira vez, este criará a chave e os valores nela contidos quando perceber que estes ainda não existem.

Os valores estarão contidos em uma sub-chave da chave que recebemos como parâmetro na rotina DriverEntry. Então, nosso trabalho básico na codificação da DriverEntry é justamente criar o caminho completo da chave do registro que conterá estes valores. Com esta UNICODE_STRING em mãos, a passaremos para as rotinas de leitura e escrita no registro. Segue abaixo a codificação da rotina DriverEntry. Ela não mostra nada de especial com relação ao registro. Como sempre, vale a pena dar uma lida nos comentários.

/****

***     DriverEntry

**

**      Ponto de entrada do nosso driver.

**      Faca nos dentes e sangue nos olhos.

*/

extern "C"

NTSTATUS

DriverEntry(__in PDRIVER_OBJECT  pDriverObject,

            __in PUNICODE_STRING pusRegistryPath)

{

    UNICODE_STRING  usParameters = RTL_CONSTANT_STRING(L"\\Parameters");

    UNICODE_STRING  usFullRegPath = {0, 0, NULL};

    PWCHAR          pwzBuffer = NULL;

    NTSTATUS        nts = STATUS_SUCCESS;

    //-f--> Aqui recebemos como parâmetro o caminho do registro até

    //      a chave do nosso driver. Nossos parâmetros estão em uma

    //      sub-chave chamada "Parameters". Vamos montar o caminho

    //      completo apendando o nome da sub-chave ao caminho do

    //      registro que recebemos como parâmetro.

    __try

    {

        __try

        {

            //-f--> Seta a rotina de callback de descarga do driver.

            pDriverObject->DriverUnload = OnDriverUnload;

            //-f--> Para fazer esse append, precisaremos de um buffer

            //      que seja grande o bastante para armazenar a string

            //      original mais o tamanho da sub-chave. Aqui alocamos

            //      este buffer.

            pwzBuffer = (PWCHAR)ExAllocatePoolWithTag(PagedPool,

                                                      pusRegistryPath->Length +

                                                      usParameters.Length,

                                                      _KRN_REG_TAG);

            if (pwzBuffer == NULL)

                ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);

            //-f--> Agora que temos o buffer, vamos inicializar a estrutura

            //      UNICODE_STRING referente a string resultante deste append.

            RtlInitEmptyUnicodeString(&usFullRegPath,

                                      pwzBuffer,

                                      pusRegistryPath->Length +

                                      usParameters.Length);

            //-f--> Copia a string recebida como parâmetro

            RtlCopyUnicodeString(&usFullRegPath,

                                 pusRegistryPath);

            //-f--> Concatena a string "\Parameters"

            RtlAppendUnicodeStringToString(&usFullRegPath,

                                           &usParameters);

            //-f--> Utilizando o caminho completo, tenta carregar os parâmetros

            nts = LoadParams(&usFullRegPath);

            if (!NT_SUCCESS(nts))

            {

                //-f--> Em caso de falha, verifica se a causa foi a falta da

                //      sub-chave no registro. Isso deve acontecer quando o

                //      driver for executado pela primeira vez. Mas se a falha

                //      for outra, então cada um com seus pobrema.

                if (nts != STATUS_OBJECT_NAME_NOT_FOUND)

                    ExRaiseStatus(nts);

                //-f--> Vamos criar a sub-chave e gravar os valores

                //      pré-definidos.

                nts = CreateParams(&usFullRegPath);

                if (!NT_SUCCESS(nts))

                    ExRaiseStatus(nts);

                //-f--> Tenta ler os parâmetros novamente.

                //      Tá, eu sei que isso é burrice. Afinal, se eu

                //      acabei de criar os parâmetros, por quê eu iria

                //      lê-los novamente? Bom, pra ilustrar.

                nts = LoadParams(&usFullRegPath);

                if (!NT_SUCCESS(nts))

                    ExRaiseStatus(nts);

            }

        }

        __finally

        {

            //-f--> Limpando a bagunça.

            if (pwzBuffer)

                ExFreePool(pwzBuffer);

        }

    }

    __except(EXCEPTION_EXECUTE_HANDLER)

    {

        //-f--> Ops!

        nts = GetExceptionCode();

        ASSERT(FALSE);

    }

    return nts;

}

Aqui é mais brincadeira de UNICODE_STRING mesmo. Vamos dar uma olhada na rotina que grava os valores no registro. Esta rotina também não oferece nada de muito diferente do que já estamos habituados a ver em User Mode. Mas é como se diz por aí: “Um exemplo vale mais que mil artigos”. Nossa, essa foi terrível! Eu preciso parar com isso. Vocês devem estar pensando agora: “Caraca! Cada coisa que a gente precisa ler pra poder ter um exemplo de driver”.

/****

***     CreateParams

**

**      Esta rotina é chamada quando não for detectada a chave

**      que contém os parâmetros. Ela cria a chave e os parâmetros

**      com valores pré-definidos.

*/

NTSTATUS

CreateParams(__in    PUNICODE_STRING pusRegistryPath)

{

    HANDLE              hKey = NULL;

    NTSTATUS            nts = STATUS_SUCCESS;

    OBJECT_ATTRIBUTES   ObjAttributes;

    UNICODE_STRING      usStringParam = RTL_CONSTANT_STRING(L"String");

    UNICODE_STRING      usDWordParam = RTL_CONSTANT_STRING(L"DoubleWord");

    ULONG               ulParam = 0x12345678;

    WCHAR               wzParam[] = L"DriverEntry.com.br";

    __try

    {

        __try

        {

            //-f--> Aqui não tem segredo. É tudo pá pum.

            InitializeObjectAttributes(&ObjAttributes,

                                       pusRegistryPath,

                                       OBJ_CASE_INSENSITIVE,

                                       NULL,

                                       NULL);

            //-f--> Cria a nova chave e já solicitamos

            //      acesso para setar valores dentro dela.

            nts = ZwCreateKey(&hKey,

                              KEY_SET_VALUE,

                              &ObjAttributes,

                              0,

                              NULL,

                              REG_OPTION_NON_VOLATILE,

                              NULL);

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

            //-f--> Seta o valor numérico

            nts = ZwSetValueKey(hKey,

                                &usDWordParam,

                                0,

                                REG_DWORD,

                                &ulParam,

                                sizeof(ulParam));

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

            //-f--> Seta o valor string

            nts = ZwSetValueKey(hKey,

                                &usStringParam,

                                0,

                                REG_SZ,

                                &wzParam,

                                sizeof(wzParam));

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

        }

        __finally

        {

            //-f--> Fecha o handle da nova chave criada

            if (hKey)

                ZwClose(hKey);

        }

    }

    __except(EXCEPTION_EXECUTE_HANDLER)

    {

        //-f--> Ops!

        nts = GetExceptionCode();

        ASSERT(FALSE);

    }

    return nts;

}

Por fim a parte mais divertida desta história. Creio que a maior parte da diversão está concentrada na rotina ZwQueryValueKey, que realiza a leitura de valores no registro.

NTSTATUS

  ZwQueryValueKey(

    IN HANDLE  KeyHandle,

    IN PUNICODE_STRING  ValueName,

    IN KEY_VALUE_INFORMATION_CLASS  KeyValueInformationClass,

    OUT PVOID  KeyValueInformation,

    IN ULONG  Length,

    OUT PULONG  ResultLength

    );

O ponto que difere da API usada em User Mode para fazer a mesma tarefa é o terceiro parâmetro KEY_VALUE_INFORMATION_CLASS. Um enum que informa quais as informações gostaríamos de obter sobre determinado valor no registro. Um deles solicita apenas o nome enquanto outro solicita todas as informações e o último informações parciais referentes ao valor.

typedef enum _KEY_VALUE_INFORMATION_CLASS {

  KeyValueBasicInformation,

  KeyValueFullInformation,

  KeyValuePartialInformation

} KEY_VALUE_INFORMATION_CLASS;

Para cada valor do enum, uma estrutura diferente é retornada. Sempre em um único bloco, a estrutura pode trazer várias informações utilizando Offsets de onde encontrar o dado dentro daquela única alocação de memória.

No exemplo, utilizei o KeyValuePartialInformation, que imagino ser o valor mais utilizado. Mais uma vez fica minha dica para que leiam os comentários trecho abaixo.

/****

***     LoadParams

**

**      Esta rotina carrega as variáveis globais com os

**      valores recuperados do registro.

*/

NTSTATUS

LoadParams(__in PUNICODE_STRING pusRegistryPath)

{

    HANDLE              hKey = NULL;

    NTSTATUS            nts = STATUS_SUCCESS;

    OBJECT_ATTRIBUTES   ObjAttributes;

    UNICODE_STRING      usStringParam = RTL_CONSTANT_STRING(L"String");

    UNICODE_STRING      usDWordParam = RTL_CONSTANT_STRING(L"DoubleWord");

    ULONG               ulBytes = 0;

    PWCHAR              pwzBuffer = NULL;

    PKEY_VALUE_PARTIAL_INFORMATION  pValueInfo = NULL;

    __try

    {

        __try

        {

            //-f--> Monta o ObjectAttribute

            InitializeObjectAttributes(&ObjAttributes,

                                       pusRegistryPath,

                                       OBJ_CASE_INSENSITIVE,

                                       NULL,

                                       NULL);

            //-f--> Tenta abrir a chave do registro

            nts = ZwOpenKey(&hKey,

                            GENERIC_READ,

                            &ObjAttributes);

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

            //-f--> Como o valor tem tamanho fixo, podemos determinar

            //      o tamanho do buffer necessário para ler o valor do

            //      registro.

            ulBytes = sizeof(KEY_VALUE_PARTIAL_INFORMATION) +

                      sizeof(ULONG) - sizeof(UCHAR);

            //-F--> Aloca o buffer para a leitura.

            pValueInfo = (PKEY_VALUE_PARTIAL_INFORMATION)

                ExAllocatePoolWithTag(PagedPool,

                                      ulBytes,

                                      _KRN_REG_TAG);

            if (!pValueInfo)

                ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);

            //-f--> Aqui fazemos a leitura.

            nts = ZwQueryValueKey(hKey,

                                  &usDWordParam,

                                  KeyValuePartialInformation,

                                  pValueInfo,

                                  ulBytes,

                                  &ulBytes);

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

            //-f--> Nos certificamos de que lemos um DWORD

            ASSERT(pValueInfo->Type == REG_DWORD);

            //-f--> Aqui nós carregamos nossa variável global

            //      com o valor lido do registro.

            g_ulParam = *(PULONG)pValueInfo->Data;

            //-f--> Libera buffer da leitura e zera ponteiro.

            //      Você pode decidir alocar o buffer de leituras

            //      baseado no maior valor que você precisa ler,

            //      e assim, utilizar o mesmo buffer para ler todos

            //      os valores menores. Aqui, mais uma vez estou

            //      refazendo tudo para demonstrar.

            ExFreePool(pValueInfo);

            pValueInfo = NULL;

            //-f--> Como a string pode ter qualquer tamanho no registro,

            //      vamos oferecer zero bytes de buffer de leitura para

            //      que a API nos diga quanto ela precisa para todo o buffer.

            nts = ZwQueryValueKey(hKey,

                                  &usStringParam,

                                  KeyValuePartialInformation,

                                  NULL,

                                  0,

                                  &ulBytes);

            //-f--> Temos que receber um destes erros.

            ASSERT(nts == STATUS_BUFFER_OVERFLOW ||

                   nts == STATUS_BUFFER_TOO_SMALL);

            //-f--> Aqui alocamos o um buffer do tamanho

            //      solicitado pela API.

            pValueInfo = (PKEY_VALUE_PARTIAL_INFORMATION)

                ExAllocatePoolWithTag(PagedPool,

                                      ulBytes,

                                      _KRN_REG_TAG);

            if (!pValueInfo)

                ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);

            //-f--> Agora faremos a leitura novamente, mas agora

            //      oferencendo um buffer de tamanho descente.

            nts = ZwQueryValueKey(hKey,

                                  &usStringParam,

                                  KeyValuePartialInformation,

                                  pValueInfo,

                                  ulBytes,

                                  &ulBytes);

            if (!NT_SUCCESS(nts))

                ExRaiseStatus(nts);

            //-f--> Temos que ter lido uma string.

            ASSERT(pValueInfo->Type == REG_SZ);

            //-f--> Agora vamos alocar o buffer que será utilizado para manter

            //     a string lida do registro. Assim podemos descartar o buffer

            //     utilizado pela leitura. O campo DataLength traz o tamanho da

            //     string unicode com o terminador zero. Repare que estra estrutura

            //     não traz uma UNICODE_STRING, e sim um array de WCHAR.

            pwzBuffer = (PWCHAR)ExAllocatePoolWithTag(PagedPool,

                                                      pValueInfo->DataLength,

                                                      _KRN_REG_TAG);

            if (!pwzBuffer)

                ExRaiseStatus(STATUS_INSUFFICIENT_RESOURCES);

            //-f--> Depois de algum tempo programando, você fica ligêro com algumas

            //      coisas. Aposto que alguém, e isso inclui a mim mesmo, um dia vai

            //      dar um Copy-Paste desta função para usar em outro lugar. Aqui,

            //      prevendo que a leitura do registro pode acontecer várias vezes,

            //      e assim, se houver a alocação de uma leitura anterior, vamos

            //      desalocá-la.

            if (g_usParam.Length)

                RtlFreeUnicodeString(&g_usParam);

            //-f--> Inicializa string global com o buffer que acabamos de alocar.

            //      Apesar de setarmos um buffer para esta UNICODE_STRING, este

            //      ainda está vazio (Length=0)

            RtlInitEmptyUnicodeString(&g_usParam,

                                      pwzBuffer,

                                      (USHORT)pValueInfo->DataLength);

            //-f--> Aqui apendamos o WCSTR (array de WCHAR terminado em zero), lido

            //      do registro em nosso buffer vazio. Isso é similar a uma cópia,

            //      mas com uma incrivel vantagem. A de não utilizar wcslen().

            //      Liga não, é paranóia de purista. Assim deixamos por conta da API

            //      determinar o Length e MaximumLegth da UNICODE_STRING. Lembre-se

            //      de que o terminador zero não é contado como parte da UNICODE_STRING.

            RtlAppendUnicodeToString(&g_usParam,

                                     (PCWSTR)pValueInfo->Data);

        }

        __finally

        {

            //-f--> Faxina geral

            if (pValueInfo)

                ExFreePool(pValueInfo);

            if (hKey)

                ZwClose(hKey);

        }

    }

    __except(EXCEPTION_EXECUTE_HANDLER)

    {

        //-f--> Ops! I did it again.

        nts = GetExceptionCode();

        ASSERT(FALSE);

    }

    return nts;

}

Ufa! Quanto código! Nesta primeira parte do assunto busquei utilizar as APIs que mais se parecem com as APIs de User Mode. No próximo post trarei uma maneira diferente de fazer a mesma coisa que fizemos aqui.

Espero ter ajudado,
Até mais…

KernelReg.zip

Essa semana recebi a seguinte pergunta de um leitor:

“É possível meu aplicativo passar um IOCTL customizável (feito por mim) para o driver, e este reconhecer sem problemas?”

A resposta à curto prazo é: “Sim, e boa sorte!”, mas que graça tem ter um blog se não podemos falar um pouco mais a respeito e até dar um exemplo assim de lambuja? Este post assume que você já sabe alguns conceitos básicos, tais como compilar, instalar e testar drivers. Mas se você ainda não sabe fazer isso, não se preocupe, a vida ainda vale a pena. Basta ler este post.

O driver que calculava

Vamos criar um driver de exemplo que usa a mesma idéia que meu amigo Heldai já usava para ilustrar o uso de IOCTLs quando eu ainda estava aprendendo a fazer telas azuis. No exemplo de hoje vamos fazer um driver que some dois números contidos em uma estrutura que será recebida via um IOCTL.

Sem mais blablablas acho que podemos começar pela definição da estrutura. Como a tia do prezinho já nos ensinou, vamos criar apenas um arquivo de header que seja incluído tanto pelo projeto da aplicação como pelo projeto do driver. Este arquivo de header não deve incluir nenhum outro arquivo de header específico de User Mode e nem de Kernel Mode, ou seja, nada de Windows.h nem de ntddk.h. Tudo isso já está prontinho, testadinho, e como meu amigo Rafael costuma dizer, “compilandinho” num projeto disponível para download ao final do post.

typedef struct _KERNEL_MATH_REQUEST

{

    //-f--> Eu posso definir minha estrutura da maneira

    //      que eu achar o maior dos melhor de bão.

    //      Estes serão os dois números a serem somados.

    ULONG   x;

    ULONG   y;

} KERNEL_MATH_REQUEST, *PKERNEL_MATH_REQUEST;

typedef struct _KERNEL_MATH_RESPONSE

{

    //-f--> Aos mais mocinhos: Eu sei que dá para fazer

    //      tudo em uma só estrutura. Estou fazendo desta

    //      forma para melhor ilustrar.

    ULONG   r;

} KERNEL_MATH_RESPONSE, *PKERNEL_MATH_RESPONSE;

Criando o IOCTL

O IOCTL é mais do que simplesmente um número para identificar a operação desejada. Ele é composto por uma máscara de bits que são interpretados pelo Windows. Esta máscara é definida como mostra a figura abaixo. Você pode obter maiores detalhes sobre esta macro neste link.

Para definir o IOCTL nós utilizamos a macro CTL_CODE que tem seus parâmentros como mostra abaixo.

#define IOCTL_Device_Function CTL_CODE(DeviceType, Function, Method, Access)

Vamos definir nosso IOCTL como mostra abaixo.

//-f--> Aqui definimos o IOCTL para nosso driver.

#define IOCTL_SOMA_QUE_EU_TO_MANDANDO \

    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)

//-f--> Apesar deste driver ter "Soma" como parte do nome, resolvi

//      colocar um IOCTL de subtração para exemplificar.

#define IOCTL_SUBTRAI_QUE_EU_TO_MANDANDO \

    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)

Agora vamos dar uma olhada em cada parâmetro que foi escolhido aqui e dar uma pincelada a respeito.

FILE_DEVICE_UNKNOWN – Dando uma olhada em nossa DriverEntry podemos verificar que este foi o mesmo tipo utilizado na chamada à rotina IoCreateDevice.

/****

***     DriverEntry

**

**      Ponto de entrada do nosso driver.

**      Faca nos dentes e sangue nos olhos.

*/

extern "C" NTSTATUS

DriverEntry(__in PDRIVER_OBJECT     pDriverObj,

            __in PUNICODE_STRING    pusRegistryPath)

{

    UNICODE_STRING  usDeviceName = RTL_CONSTANT_STRING(L"\\Device\\KernelSum");

    UNICODE_STRING  usSymbolicLink = RTL_CONSTANT_STRING(L"\\DosDevices\\KernelSum");

    NTSTATUS        nts;

    PDEVICE_OBJECT  pDeviceObj;

    //-f--> Setando a rotina de unload e permitir que o driver

    //      possa ser descarregado dinamicamente

    pDriverObj->DriverUnload = OnDriverUnload;

    //-f--> As rotinas de Open, Cleanup e Close são idênticas.

    //      Então, pela lei do mínimo esforço, serão uma única.

    //      Além dessa, temos que tratar a DeviceControl, que é

    //      onde os IOCTLs são recebidos

    pDriverObj->MajorFunction[IRP_MJ_CREATE] =

    pDriverObj->MajorFunction[IRP_MJ_CLEANUP] =

    pDriverObj->MajorFunction[IRP_MJ_CLOSE] = OnCreateCleanupClose;

    pDriverObj->MajorFunction[IRP_MJ_DEVICE_CONTROL] = OnDeviceIoControl;

    //-f--> Criamos o device de controle do driver. Repare que utilizamos

    //      FILE_DEVICE_UNKNOWN como device type. Este mesmo device type

    //      é utilizado na macro CTL_CODE. Veja: IoCtl.h

    nts = IoCreateDevice(pDriverObj,

                         0,

                         &usDeviceName,

                         FILE_DEVICE_UNKNOWN,

                         0,

                         FALSE,

                         &pDeviceObj);

    //-f--> Tudo bem até aqui? Então beleza...

    if (!NT_SUCCESS(nts))

    {

        ASSERT(FALSE);

        return nts;

    }

    //-f--> Cria symbolic link para que a aplicação consiga

    //      obter um handle para o device de controle

    nts = IoCreateSymbolicLink(&usSymbolicLink,

                               &usDeviceName);

    //-f--> Tá tudo bem?

    if (!NT_SUCCESS(nts))

    {

        //-f--> Ops... Acho que eu pisei em alguma coisa mole...

        IoDeleteDevice(pDeviceObj);

        ASSERT(FALSE);

        return nts;

    }

    //-f--> Beleza, fechou, é nóis na fita!

    return STATUS_SUCCESS;

}

O segundo parâmetro, o Function, recebe o número 0x800, já que os números abaixo disso são reservados à Microsoft.

METHOD_BUFFERED – Indica ao IoManager que o driver receberá uma cópia do buffer de entrada passado à função DeviceIoControl. O IoManager aloca um buffer de sistema, ou seja, em Kernel Space, suficientemente grande para que caibam tanto os dados de entrada como os dados de saída. Quando a função DeviceIoControl é chamada, o IoManager aloca o buffer de sistema e copia o buffer de entrada para dentro dele. O driver recebe a IRP, obtém os parâmetros de entrada, processa-os e escreve os dados de saída no mesmo buffer de sistema. Quando a IRP é completada, o IoManager copia os dados de saída do buffer de sistema para o buffer de saída oferecido pela aplicação.

Além do método Buffered, ainda existem os métodos de Direct I/O e Neither. Para o nosso exemplo de hoje, o méthodo Buffered está ótimo. Fico devendo um post que fala sobre como usar cada um dos outros métodos.

FILE_ANY_ACCESS – Indica que o handle não precisa ser aberto com um tipo de acesso especial para poder executar este IOCTL.

Da aplicação para o driver

Para enviar um IOCTL para o driver, você precisa utilizar a função DeviceIoControl como mostra o exemplo abaixo. Este é um programa bem simples que mostra este uso.

/****

***     main

**

**      Espero que todos saibam que este é o ponto

**      de entrada de uma aplicação. Caso contrário,

**      você pode estar se preciptando em ler um blog

**      de driver para Windows.

*/

int __cdecl main(int argc, CHAR* argv[])

{

    HANDLE                  hDevice;

    DWORD                   dwError = ERROR_SUCCESS,

                            dwBytes;

    KERNEL_MATH_REQUEST     Request;

    KERNEL_MATH_RESPONSE    Response;

    printf("Opening \\\\.\\KernelSum device...\n");

    //-f--> Aqui abrimos um handle para o nosso device que

    //      foi criado pelo driver. Vale lembrar que nosso

    //      driver de exemplo tem que ser instalado e iniciado

    //      para que a chamada abaixo funcione corretamente.

    hDevice = CreateFile("\\\\.\\KernelSum",

                         GENERIC_ALL,

                         0,

                         NULL,

                         OPEN_EXISTING,

                         0,

                         NULL);

    //-f--> Verifica se o handle foi aberto.

    if (hDevice == INVALID_HANDLE_VALUE)

    {

        printf("Error #%d opening device...\n",

               (dwError = GetLastError()));

        return dwError;

    }

    //-f--> Fiquei com preguiça e coloquei os valores hard-coded mesmo.

    Request.x = 3;

    Request.y = 2;

    printf("Calling DeviceIoControl...\n");

    //-f--> Envia o IOCTL

    if (!DeviceIoControl(hDevice,

                         IOCTL_SOMA_QUE_EU_TO_MANDANDO,

                         &Request,

                         sizeof(KERNEL_MATH_REQUEST),

                         &Response,

                         sizeof(KERNEL_MATH_RESPONSE),

                         &dwBytes,

                         NULL))

    {

        //-f--> Ops...

        printf("Error #%d calling DeviceIoControl...\n",

               (dwError = GetLastError()));

        CloseHandle(hDevice);

        return dwError;

    }

    //-f--> Mostrando resultatdos

    printf("%d + %d = %d\n",

           Request.x,

           Request.y,

           Response.r);

    printf("Closing device...\n");

    //-f--> Fim de conversa

    CloseHandle(hDevice);

    return 0;

}

Note que não existe nenhuma amarração forte entre o IOCTL e os bufferes de entrada ou de saída utilizados, mas é preciso ficar atento aos tamanhos dos bufferes quando o driver fizer uso deles. Ninguém vai querer corromper o heap de alocações de Kernel ou sair disparando excessões em Kernel Mode, vai?

Vejam como os dados são tratados pelo driver ao receber a IRP_MJ_DEVICE_CONTROL. Leiam os comentários, eles fazem parte do texto explicativo. Nossa, até que essa frase que representa a minha preguiça ficou legal. No fundo mesma frase quer dizer: “Ah meu! Fala sério que além de preparar esse exemplo, você ainda quer que eu duplique toda a informação dos comentários. E na bunada não vai dinha?”

/****

***     OnDeviceIoControl

**

**      Esta rotina é chamada quando uma aplicação

**      envia um IOCTL via DeviceIoControl para nosso device.

*/

NTSTATUS

OnDeviceIoControl(__in PDEVICE_OBJECT   pDeviceObj,

                  __in PIRP             pIrp)

{

    PIO_STACK_LOCATION      pStack;

    NTSTATUS                nts;

    PKERNEL_MATH_REQUEST    pRequest;

    PKERNEL_MATH_RESPONSE   pResponse;

    //-f--> Obtemos os parâmetros para nosso driver

    pStack = IoGetCurrentIrpStackLocation(pIrp);

    switch(pStack->Parameters.DeviceIoControl.IoControlCode)

    {

    case IOCTL_SOMA_QUE_EU_TO_MANDANDO:

    case IOCTL_SUBTRAI_QUE_EU_TO_MANDANDO:

        //-f--> Vamos fazer as verificações de tamanho dos

        //      buffers de entrada e saída.

        if (pStack->Parameters.DeviceIoControl.InputBufferLength !=

            sizeof(KERNEL_MATH_REQUEST) ||

            pStack->Parameters.DeviceIoControl.OutputBufferLength !=

            sizeof(KERNEL_MATH_RESPONSE))

        {

            nts = STATUS_INVALID_BUFFER_SIZE;

            pIrp->IoStatus.Information = 0;

            break;

        }

        //-f--> O seguro morreu de velho.

        ASSERT(pIrp->AssociatedIrp.SystemBuffer != NULL);

        //-f--> Utilizando METHOD_BUFFERED, o sistema aloca um buffer único

        //      para transportar os dados de entrada e de saída. O tamanho

        //      este buffer é mesmo do maior deles. Assim, tome cuidado

        //      para não escrever nada na saída antes de ler toda a entrada.

        pRequest = (PKERNEL_MATH_REQUEST)pIrp->AssociatedIrp.SystemBuffer;

        pResponse = (PKERNEL_MATH_RESPONSE)pIrp->AssociatedIrp.SystemBuffer;

        //-f--> Faz a operação e sinaliza sucesso

        if (pStack->Parameters.DeviceIoControl.IoControlCode == IOCTL_SOMA_QUE_EU_TO_MANDANDO)

            pResponse->r = pRequest->x + pRequest->y;

        else

            pResponse->r = pRequest->x - pRequest->y;

        nts = STATUS_SUCCESS;

        //-f--> Informa ao IoManager quantos bytes devem ser tranferidos de

        //      volta para a aplicação

        pIrp->IoStatus.Information = sizeof(KERNEL_MATH_RESPONSE);

        break;

    default:

        //-f--> Ops... Recebemos um IOCTL não previsto.

        nts = STATUS_INVALID_DEVICE_REQUEST;

        pIrp->IoStatus.Information = 0;

    }

    //-f--> Copia o status final da IRP e a completa.

    pIrp->IoStatus.Status = nts;

    IoCompleteRequest(pIrp, IO_NO_INCREMENT);

    //-f--> NOTA: Lembre-se de que não podemos tocar na IRP depois de completa-la,

    //      então não seja espertão modificando a linha abaixo para a obter o Status

    //      de dentro da IRP, e assim usa-lo como retorno de função.

    return nts;

}

Compilando assim ou assado

O projeto de exemplo que está disponível para download ao final deste post pode ser compilado de duas maneiras. Uma delas é utilizando a maneira padrão de compilar drivers oferecida pelo WDK. Resumidamente você vai em Start->All Programs->Windows Drivers Kits->WDK 6000->Build Environments->Windows XP->Windows XP x86 Checked Build Environment. Isso deve abrir uma jabela de prompt como mostra abaixo. Depois disso é só ir ao diretório onde você baixa essas tranqueiras da internet e entrar no diretório raiz do projeto. Lá você chama o Build.exe e um abraço.

A outra maneira de compilar todo o projeto permite que você compile de dentro do Visual Studio 2008, que foi o ambiente que utilizei para compor este projeto. Porém, para compilar o projeto pela IDE, você precisará usar o DDKBUILD como mostra este outro post que fala a respeito.

Enquanto estive fora, recebi uma outra dúvida de um leitor que queria saber como ler/escrever no registro usando um driver. No próximo post falarei sobre isso além de outros detalhes referentes ao registro do ponto de vista de um driver.

Até lá!

KernelSum.zip

Mais uma vez fiquei sem postar por um longo tempo. Agora você deve estar pensando: “Lá vem ele com aquela ladainha de que não tem tempo, que tudo está difícil, que Deus não gosta dos programadores de Kernel e assim por diante”. Bom, vou pular essa parte de dar minhas desculpas e vou logo dizendo o que estive fazendo durante esse tempo.

Curso de Drivers para Windows

Bom deixe-me ver onde foi mesmo que eu parei. Meu último post foi durante o período em que eu estava dando um curso de desenvolvimento de drivers para uma turma fechada. O curso foi ministrado em cinco sábados de 8 horas cada. Não preciso dizer que isso me ocupou por um tempo. Tá tá tá, sem desculpas.

Quarto Encontro de Programadores de C/C++

No sábado subsequente ao final do curso, fui dar uma passeada neste evento. Deixaram a porta meio aberta e consegui entrar para dar uma espiada e falar um pouco sobre Arquitetura e Desenvolvimento de drivers para Windows com linguagem C. Confesso que o convite para participar deste evento foi uma surpresa para mim. Não sou um grande programador de C++, mas utilizo a linguagem C com classes como meu amigo Strauss gosta de dizer. Posso dizer que foi muito interessante poder participar desse evento de altíssimo nível técnico e ter a oportunidade de ver como a linguagem pode ser utilizada em diferentes cenários. Os slides da minha palestra estão disponíveis neste link.

De volta à Boston

Até parece que as coisas só acontecem aos sábados. De qualquer forma, no sábado subsequente ao encontro, embarquei em uma viajem de um mês para Boston. Da última vez que estive por lá foi para fazer um treinamento na OSR como descrevi neste post. Desta vez foi um programa de integração da IBM. Pude conhecer pessoalmente as pessoas com quem trabalho e que antes só conhecia por Web Conferência. Mais uma vez foi bem interessante e tentei aproveitar ao máximo. Fomos em dois brasileiros e um Indiano. Senti muita saudade do nosso cafézinho brasileiro. Nessa foto abaixo estão, da esquerda para a direita, David E. Jones (Gerente), Scott D. Hankin (Documentação), William C. Oliveira (Linux), William H. Taber (Linux), Mridula Muppana (Testes), Paul Ganshirt (Windows), Niraj Kumar (AIX), Kaveesh Mishra (Windows), Fernando Roberto (Windows) e Richard Kissel (AIX e Linux). Esta é apenas uma parte de todo o time de MVFS.

Não sabe o que é MVFS? É um File System que faz parte de um produto chamado ClearCase. Não conhece o ClearCase? Bom, além da Wikipedia, pude ter o prazer de esbarrar com uma observação sobre o ClearCase no livro de Rajeev Nagar. Este livro, como eu não me canso de dizer, ainda é a única referência respeitável sobre desenvolvimento de File Systems para Windows apesar de ter sido publicado pela primeira vez em 1997. Mas onde está o ClearCase nesta história? Bom, se você é doente como eu e tem esse livro, dê uma olhadinha no início do capítulo nove. Na primeira página deste capítulo você encontrará as seguintes passagens.

Isso é realmente muito legal! 🙂

Volta às aulas

Durante um mês inteiro após minha chegada de volta ao Brasil, dediquei algum tempo correndo atrás da matéria que perdi na faculdade. Pois é, ainda estou me graduando em Engenharia da Computação. Já estou trabalhando em meu TCC (Trabalho de Conclusão de Curso). Meu TCC terá obrigatóriamente que ter um driver de Windows, é o mínimo que eu poderia fazer. Finalmente vou poder mostrar o que sei fazer aos meus amiguinhos de sala. Durante o curso, alguns amigos me perguntam com o quê eu trabalho, já que freqüentemente estou lendo grandes livros da Microsoft. Depois de tentar explicar das maneiras mais simples possíveis, desenhando ou mesmo usando fantoches, eles ainda ficam com aquela cara de interrogação. Bom, na hora que eu mostrar a tela azul, eles vão acabar entendendo.

Aproveitei o passeio nos Estados Unidos para comprar esse kit de desenvolvimento da ALTERA. Esse kit vai fazer parte do meu TCC e futuramente poderei utilizá-lo em meus cursos de desenvolvimento de drivers. Hoje conto apenas com as placas de treinamento da OSR, conforme já falei a respeito neste post. Diferente das placas da OSR, este kit pode ter seu hardware definido por uma linguagem chamada VHDL, e assim, poderei fazer com que a placa tenha os mais variados comportamentos e poderei ilustrar a construção de drivers de interface para cada situação. Essa placa custa em torno de R$ 1.700,00 aqui no Brasil, enquanto que paguei apenas US$ 150,00 lá. Praticamente veio no doce. Sabe quando íamos à padaria comprar aquela casquinha de sorvete que vem recheada com maria-mole, e enfiada nela vem um brinquedo. Então, foi quase a mesma coisa. Uma outra coisa interessante nesse kit, além do preço, é que é possível fazer interface USB e interface PCI. Isso vai ser bem divertido.

Seminário de Portabilidade e Performance

Neste último final de semana, participei de mais esse evento organizado pelo grupo de C/C++ Brasil. É impressionante ver como estes eventos estão trazendo cada vez mais gente. Bati algumas fotos, mas vou deixar os comentários por conta do meu amigo Lesma, que já fez um post muito legal à respeito.

De volta ao mundo dos bloggers, vou tentar não abandoná-los por tanto tempo. Desculpinhas à parte, num tá fáci não.

Até a próxima.

Já comentei em outro post que é possível fazer Kernel Debugging através de uma porta USB 2.0. Neste post vou demonstrar essa tal conexão USB 2.0 funcionando. Ê laiá coisa boa. Então vamos deixar de conversinha mole e vamos logo ao que interessa. Se você não entende nada sobre Kernel Debugging, você pode ler este post, que tráz os conceitos e passos básicos sobre o assunto, ou você pode se perguntar “Como é que eu fui cair neste site?” e voltar para o ORKUT.

O barramento USB não permite que tenhamos conexões diretas entre dois computadores. Para que possamos utilizar uma porta USB para este fim, teremos que contar com a ajuda de um hardware adicional. Apesar de receber o nome de Debug Cable, trata-se de um pequeno dispositivo que une os computadores através de portas USB. Não sei se já existem outros fabricantes para o Debug Cable, mas o que vou utilizar neste experimento é o NET20DC.

Utilizando o Debug Cable

Utilizar o Debug Cable é um luxo que apenas o Windows Vista ou sistemas posteriores podem desfrutar. Ele precisa ser conectado a uma porta USB 2.0 sem passar por nenhum HUB do lado TARGET. Mas como saber com certeza quais das minhas portas é de fato 2.0?

Uma maneira fácil de saber isso, principalmente para quem tem o WDK instalado, é compilar o exemplo USBView, que está na pasta “C:\WinDDK\6000\src\usb\usbview” do WDK. Este programa enumera os controladores e os respectivos dispositivos USB conectados. Desta forma, quando conectarmos o Debug Cable à máquina TARGET, o USBView deve informar em qual porta este novo dispositivo está conectado. Repare que nesta janela podemos ver em qual controlador a porta que estamos utilizando pertence.

O Windows solicitará um driver ao detectar a presença deste novo dispositivo USB. Do lado TARGET nenhum driver precisa ser instalado para utilizar o Debug Cable. Assim você pode selecionar “Não exibir esta mensagem novamente para este dispositivo” na janela da figura abaixo. Não instalar nenhum driver faz todo o sentido do lado TARGET. Lembre-se de quem vai utilizar esta interface de debug do lado TARGET é a BIOS, e vai repassar o controle para o core do sistema operacional. Vale lembrar também que existe um outro requisito para utilizar o Debug Cable é que a BIOS da máquina TARGET implementar este controle de interface de debug. A parte mais infeliz desta história é que para saber se a sua BIOS está preparada ou não, basta tentar. Ou seja, você pode ter o Debug Cable, uma porta USB 2.0 livre, os cabos e ainda assim correr o risco de nada conectar pelo simples fato da BIOS não dar suporte. Fico feliz em saber que meu notebook dá esse suporte e que não gastei essa grana a toa importando o Debug Cable. Ufa!!

Modificando o Boot.ini

Hêin? Boot.ini? Isso não te pertence mais. O Windows Vista utiliza uma nova arquitetura chamada Boot Configuration Data (BCD). Isso levou nosso amigo Boot.ini para a casa do chapéu. Para editar as configurações do BCD, utilizamos a ferramenta BCDEdit.exe, uma aplicação console que precisa ser executada com poderes administrativos. A execução desta ferramenta sem qualquer parâmetro nos retorna a seguite saída.

Para configurar o sistema de forma a termos duas opções de boot, uma com debug habilitado e outra não, siga os passos abaixo descritos. O Boot Manager gerencia Boot Loaders, que podem ser outros sistemas operacionais, mesmo que anteriores ao Windows Vista, como também podem ser conjuntos de configurações do mesmo sistema. Cada um destes ítens é identificado por um GUID. Observe que o primeiro comando faz uma cópia da configuração atual para uma que contenha a string “Windows Vista Cobaia Mode” como descrição. Em resposta a essa cópia, a ferramenta nos retorna o GUID resultante da cópia realizada. Observe também que no segundo comando habilitamos o debug de kernel para a configuração identificada pelo GUID que acabamos de receber. Neste momento, se dermos uma olhada nas configurações teremos o resultado como é exibido na mesma imagem abaixo.

Beleza, agora temos que configurar o meio de comunicação que será utilizado pelo Kernel Debugger. creio que a maioria dos micros ainda utilizem portas seriais para este fim. Neste caso, a configuração mais comum seria a de utilizar a porta serial COM1 com um baudrate de 115200. Para setar estas configurações, utilize a seguinte linha de comando. Para ver as configurações atuais, basta executar a segunda linha de comanodo como exibida abaixo.

Se você ainda não sabe como utilizar a porta serial como meio de comunicação para o debug de kernel, este post fala a respeito. Entretando, neste post vou comentar sobre o debug de kernel utilizando uma porta USB 2.0 como meio de comunicação. Neste caso as configurações serão as descritas na linha de comando exibida abaixo. O TARGETNAME pode receber qualquer nome. Utilizei o nome “WINDBG” por motivos óbvios, mas você pode colocar qualquer nome.

Como vocês podem ter imaginado, as configurações sobre o meio de comunicação de debug são globais, ou seja, não estão vinculadas a esta ou àquela configuração de boot identificada por um GUID.

Creio que do lado TARGET já está tudo pronto para efetuar o link. Desta forma, quando reiniciarmos o computador vítima teremos o seguinte menu exibido pelo Boot Manager.

Configurando o HOST

Do lado HOST desta brincadeira, teremos que adicionar o driver que controla o Debug Cable e permitir que o Windbg possa utilizar este dispositivo. Apesar de eu estar utilizando Windows Vista no lado HOST, nada impede de você utilizar o Windows 2000 ou superior neste lado da conversa. A brincadeira começa quando você pluga o dispositivo e clica em “Localizar e instalar o driver (recomendado)” na janela de “Novo hardware encontrado” já exibida neste post. Neste momento o Windows procura pelo driver no banco de dados do Windows Update.

A coisa começa a ficar divertida quando o Windows me pede para inserir o disco que veio com o Debug Cable. Apenas duas palavras ficaram em minha mente neste momento: “Que disco?”. Sem muitas opções eu cliquei em “Eu não tenho essa porcaria de disco! Cê tá loco? Me mostre qualquer coisa pelo amor de Deus”. Alguns de vocês já devem até ter esta seqüência de janelas decoradas de tanto não encontrar drivers para todos os dispositivos que você tem.

Por fim quando a última janela me foi mostrada, me veio uma luz, mais uma daquelas idéias brilhantes que tenho a cada ano bisexto. Foi quando pensei comigo mesmo “Já sei! Vou visitar o site do fabricante e procurar por uma sessão de suporte.”.

E no site do fabricante…

E no site da Microsoft…

Em fim, mandei o tal e-mail para obter qualquer sinal de que eu não tivesse jogado meu dinheiro no lixo. Em menos de uma hora recebo a resposta com uma lista de requisitos e passos a serem seguidos, mas o mais importante só me foi revelado no final.

Eu sabia que podia contar com a inteligência e a agilidade da Microsoft para resolver isso. Mas fica minha dica para os que estão lendo este post. Quando o Windows solicitar o driver do novo dispositivo, aponte a pasta “C:\Program Files\Debugging Tools for Windows\usb”.

E é com prazer que vos mostro a janela a seguir:

Configurando o Windbg

Agora é brincadeira de criança. Selecione o ítem “Kernel Debug…” do menu “File”. Clique na aba “USB 2.0” e coloque o mesmo TARGETNAME que você escolheu lá na configuração do TARGET com o BCDEdit.exe. No meu caso, o nome é WINDBG como exibido ao lado.

Clicando em OK, a janela de comandos do WinDbg deve exibir o texto destacado em vermelho a seguir, e ficar esperando a conexão se completar. A saída abaixo foi obtida com um CTRL+Break após o debugger ter conectado.

Microsoft (R) Windows Debugger Version 6.8.0004.0 AMD64

Copyright (c) Microsoft Corporation. All rights reserved.

Using USB2 for debugging

Waiting to reconnect...

USB2: Write opened

Connected to Windows Vista 6000 x86 compatible target, ptr64 FALSE

Kernel Debugger connection established.

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Executable search path is:

Windows Vista Kernel Version 6000 MP (1 procs) Free x86 compatible

Built by: 6000.16584.x86fre.vista_gdr.071023-1545

Kernel base = 0x82000000 PsLoadedModuleList = 0x82111e10

System Uptime: not available

Break instruction exception - code 80000003 (first chance)

*******************************************************************************

*                                                                             *

*   You are seeing this message because you pressed either                    *

*       CTRL+C (if you run kd.exe) or,                                        *

*       CTRL+BREAK (if you run WinDBG),                                       *

*   on your debugger machine's keyboard.                                      *

*                                                                             *

*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *

*                                                                             *

* If you did not intend to break into the debugger, press the "g" key, then   *

* press the "Enter" key now.  This message might immediately reappear.  If it *

* does, press "g" and "Enter" again.                                          *

*                                                                             *

*******************************************************************************

nt!RtlpBreakWithStatusInstruction:

820818d0 cc              int     3

0:kd>

Agora acabou a parte fácil, os próximos passos já serão referentes a encontrar o bug. Mas isso vai ter que ficar para um outro post.

Espero ter ajudado.
T+ 🙂

Olá pessoal, prometo que este post vai ser curtinho. Essa notícia é para os escovadores de bit de plantão.

No próximo dia 29 de março, acontecerá o Quarto Encontro de Programadores que é organizado pelo grupo de C/C++ Brasil.

O evento vai trazer uma série de palestras com verdadeiras autoridades no assunto. Acho que o único ilustre desconhecido serei eu mesmo. Fui convidado para falar um pouco sobre arquitetura e desenvolvimento de drivers para Windows.

Se você não tem a menor idéia de como os drivers são organizados e de como você pode construí-los, então esta é sua chance de continuar assim, mas com uma boa oportunidade de ver outras excelentes palestras. Já dei alguns treinamentos, mas não posso dizer que tenho grandes experiências com palestras. Acho que a maior palestra que já dei era composta por um público de aproximadamente de três pessoas. Isso contando com a minha mãe que ficava o tempo todo me mandando calar a boca pra ela poder ouvir a novela.

De qualquer forma vou me esforçar para não fazer feio por lá. Felizmente meu amigo Strauss, que por sinal será um dos palestrantes, me deu uma forcinha publicando este post com dicas para palestrantes.

Até mais…

Há um tempo atrás, meu amigo Lesma publicou um post sobre suas aventuras Kernel a dentro em busca do motivo de uma tela azul. O problema foi causado por uma chamada incorreta à função KeWaitForMultipleObjects na tentativa de esperar por 4 objetos. Pois é Wanderley, isso que é dá herdar código de Deus e o mundo. Enfim é aquela coisa toda. Só porque a função tem a palavra “Múltiplo” no nome, não significa que podemos esperar por essa quantidade absurda de 4 objetos. Neste post vou dar um simples exemplo de como utilizar esta função.

Onde mora o limite?

A função KeWaitForMultipleObjects utiliza de um array de elementos do tipo KWAIT_BLOCK que contém os dados referentes aos múliplos objetos da espera que será realizada. Em muitos casos, essa quantidade de múltiplos objetos que participam da espera não passa de três objetos. A fim de evitar de sempre ter de construir um array de estruturas de KWAIT_BLOCK para realizar uma espera múltipla, a estrutura que representa uma thread em Kernel mode, a KTHREAD, contém um array de quatro elementos desta estrutura embutida nela, como se pode observar abaixo.

kd> dt nt!_KTHREAD

   +0x000 Header           : _DISPATCHER_HEADER

   +0x010 MutantListHead   : _LIST_ENTRY

   +0x018 InitialStack     : Ptr32 Void

   +0x01c StackLimit       : Ptr32 Void

   +0x020 Teb              : Ptr32 Void

   +0x024 TlsArray         : Ptr32 Void

   +0x028 KernelStack      : Ptr32 Void

   +0x02c DebugActive      : UChar

   +0x02d State            : UChar

   +0x02e Alerted          : [2] UChar

   +0x030 Iopl             : UChar

   +0x031 NpxState         : UChar

   +0x032 Saturation       : Char

   +0x033 Priority         : Char

   +0x034 ApcState         : _KAPC_STATE

   +0x04c ContextSwitches  : Uint4B

   +0x050 IdleSwapBlock    : UChar

   +0x051 Spare0           : [3] UChar

   +0x054 WaitStatus       : Int4B

   +0x058 WaitIrql         : UChar

   +0x059 WaitMode         : Char

   +0x05a WaitNext         : UChar

   +0x05b WaitReason       : UChar

   +0x05c WaitBlockList    : Ptr32 _KWAIT_BLOCK

   +0x060 WaitListEntry    : _LIST_ENTRY

   +0x060 SwapListEntry    : _SINGLE_LIST_ENTRY

   +0x068 WaitTime         : Uint4B

   +0x06c BasePriority     : Char

   +0x06d DecrementCount   : UChar

   +0x06e PriorityDecrement : Char

   +0x06f Quantum          : Char

   +0x070 WaitBlock        : [4] _KWAIT_BLOCK

   +0x0d0 LegoData         : Ptr32 Void

   +0x0d4 KernelApcDisable : Uint4B

   +0x0d8 UserAffinity     : Uint4B

   +0x0dc SystemAffinityActive : UChar

   +0x0dd PowerState       : UChar

   +0x0de NpxIrql          : UChar

   +0x0df InitialNode      : UChar

   +0x0e0 ServiceTable     : Ptr32 Void

   +0x0e4 Queue            : Ptr32 _KQUEUE

   +0x0e8 ApcQueueLock     : Uint4B

   +0x0f0 Timer            : _KTIMER

   +0x118 QueueListEntry   : _LIST_ENTRY

   +0x120 SoftAffinity     : Uint4B

   +0x124 Affinity         : Uint4B

   +0x128 Preempted        : UChar

   +0x129 ProcessReadyQueue : UChar

   +0x12a KernelStackResident : UChar

   +0x12b NextProcessor    : UChar

   +0x12c CallbackStack    : Ptr32 Void

   +0x130 Win32Thread      : Ptr32 Void

   +0x134 TrapFrame        : Ptr32 _KTRAP_FRAME

   +0x138 ApcStatePointer  : [2] Ptr32 _KAPC_STATE

   +0x140 PreviousMode     : Char

   +0x141 EnableStackSwap  : UChar

   +0x142 LargeStack       : UChar

   +0x143 ResourceIndex    : UChar

   +0x144 KernelTime       : Uint4B

   +0x148 UserTime         : Uint4B

   +0x14c SavedApcState    : _KAPC_STATE

   +0x164 Alertable        : UChar

   +0x165 ApcStateIndex    : UChar

   +0x166 ApcQueueable     : UChar

   +0x167 AutoAlignment    : UChar

   +0x168 StackBase        : Ptr32 Void

   +0x16c SuspendApc       : _KAPC

   +0x19c SuspendSemaphore : _KSEMAPHORE

   +0x1b0 ThreadListEntry  : _LIST_ENTRY

   +0x1b8 FreezeCount      : Char

   +0x1b9 SuspendCount     : Char

   +0x1ba IdealProcessor   : UChar

   +0x1bb DisableBoost     : UChar

Destes quatro elementos, três são destinados a serem utilizados pela KeWaitForMultipleObjects, enquanto o que quarto elemento é de uso reservado do sistema para implementar a espera com timeout.

Para esperar até 3 objetos, o código da espera ficaria como segue abaixo:

    //-f--> Array de PVOIDs

    PVOID       pObjects[3];

    //-f--> Temos que inicializar um array de ponteiros para

    //      os objetos os quais a espera será baseada.

    pObjects[0] = &kEvent1;

    pObjects[1] = &kEvent2;

    pObjects[2] = &kEvent3;

    //-f--> Chamada simples para uma espera múltipla de

    //      3 objetos.

    nts = KeWaitForMultipleObjects(3,

                                   pObjects,

                                   WaitAll,

                                   Executive,

                                   KernelMode,

                                   FALSE,

                                   NULL,

                                   NULL);

Isso significa que não podemos esperar por mais de 3 objetos por vez? Também não é bem assim. Quando for necessário esperar por mais de três objetos, teremos que alocar um buffer grande o suficiente para manter um array de N elementos da estrutura KWAIT_BLOCK. Onde N é menor ou igual a 64. Se houver mais objetos que isso, teremos um belo MAXIMUM_WAIT_OBJECTS_EXCEEDED.

“If a buffer is supplied, the Count parameter may not exceed MAXIMUM_WAIT_OBJECTS. If no buffer is supplied, the Count parameter may not exceed THREAD_WAIT_OBJECTS.”

//-f--> From wdm.h

#define THREAD_WAIT_OBJECTS 3       // Builtin usable wait blocks

#define MAXIMUM_WAIT_OBJECTS 64     // Maximum number of wait objects

Neste caso, para uma espera de 10 objetos teríamos o seguinte código:

   //-f--> Array de PVOIDs

    PVOID           pObjects[10];

    //-f--> Array adicional de KWAIT_BLOCKs

    PKWAIT_BLOCK    pWaitBlocks = NULL;

    //-f--> Temos que inicializar um array de ponteiros para

    //      os objetos os quais a espera será baseada.

    pObjects[0] = &kEvent1;

    pObjects[1] = &kEvent2;

    pObjects[2] = &kEvent3;

    pObjects[3] = &kEvent4;

    pObjects[4] = &kEvent5;

    //-f--> Por encreça que parível, eu sei usar loops e arrays,

    //      mas fica mais didático mostrar que os objetos não

    //      precisam necessariamente estar em um array, enquanto

    //      que os ponteiros para eles sim.

    pObjects[5] = &kEvent6;

    pObjects[6] = &kEvent7;

    pObjects[7] = &kEvent8;

    pObjects[8] = &kEvent9;

    pObjects[9] = &kEvent10;

    //-f--> Não poderemos utilizar o array de KWAIT_BLOCKS

    //      embutido na KTHREAD, teremos que alocar o nosso array.

    pWaitBlocks = (PKWAIT_BLOCK) ExAllocatePool(NonPagedPool,

                                                sizeof(KWAIT_BLOCK) * 10);

    //-f--> Testar alocação não mata ninguém, mas tenta não

    //      testar para ver quantos morrem.

    ASSERT(pWaitBlocks != NULL);

    //-f--> Chamada simples para uma espera múltipla de

    //      10 objetos e sem bug-check.

    nts = KeWaitForMultipleObjects(10,

                                   pObjects,

                                   WaitAll,

                                   Executive,

                                   KernelMode,

                                   FALSE,

                                   NULL,

                                   pWaitBlocks);

    //-f--> Memory leak é falta de educação

    ExFreePool(pWaitBlocks);

Resumidamente é isso aí.
Até mais mais…

Se um dos problemas que impediam você de fazer um treinamento especializado em desenvolvimento de device drivers na OSR era o fato de ter medinho de voar, então seus pobremas se acabaram-se. A OSR, depois de anos e anos de experiência ensinando a escrever drivers, agora investe nos Webinars. Essa novidade já está anunciada desde o dia 4 de janeiro, mas ainda causa surpresa quando comento com algumas pessoas. Assim, resolvi colocar esse post e tentar repassar a novidade para mais pessoas de uma só vez.

Mais barato?

A vantagem financeira está no fato de evitar de comprar as passagens aéreas e pagar a hospedagem de uma semana nos Estados Unidos. Tá, tudo bem, não é você quem vai pagar mesmo, mas pense que nem todos trabalham em empresas multi-nacionais com milhares de dólares destinados a treinamentos de funcionários. Quando fiz o treinamento na OSR, tudo foi pago pela empresa onde eu trabalhava, mas se eu colocar tudo na ponta do lápis, foram cerca de R$13000 de investimento para participar de um seminario de U$2350, que na cotação de hoje seriam traduzidos em aproximadamente R$4143, ou seja, aproximadamente um terço do valor total. Isso pode simplesmente ser o fator que vai impedir você de fazer o treinamento. Então, você já pode ir correndo dizer pro papai e pra mamãe que eles agora têm mais poder aquisitivo para treinar você. Mas não três vezes mais. Pelo que me parece, os Webinars são relativamente mais caros que os seminários convecionais. O seminário que participei teve duração de 32 horas e abordava o desenvolvimento de drivers de File System (um assunto um cadim avançado), enquanto O primeiro webinar oferecido pela OSR fará uma rápida introdução ao WDF durante 20 horas pelo mesmo preço.

Outras vantagens

Um outro ponto bastante relevante é o fato de não ter que se ausentar de sua casa ou da empresa que você trabalha durante o seminário. Algumas das pessoas com quem conversei a respeito, me disseram que um grande problema é o fato de ter que sair de casa durante uma semana inteira. Alguns deles têm filhos pequenos ou outros tantos motivos que você pode imaginar, mas creio que o motivo mais comum que pode prender o profissional, são os intermináveis pepinos inadiáveis que só você pode resolver. Bom pelo menos este webinar é composto por 5 aulas de 4 horas. Isso permite que você cuide de sua pequena hortinha de pepinos enquanto participa dos treinamentos.

Não é apenas um ppt bem caro

Ao contrário do que se pode imaginar, os seminários serão interativos utilizando conexões de duas vias onde o participante poderá, além de receber todas as instruções ao vivo, fazer perguntas e ainda receber todo o material impresso como nos outros seminários. O interessado no webinar fará o download da ferramenta que estabelece a conexão e participará de uma sessão de 15 minutos para testar o computador que será usado nas sessões, e assim, certificar-se de que o participante não terá qualquer problema durante o treinamento.

Agora, se sua empresa não quiser mesmo pagar um treinamento pra você, já fica pelo menos mais fácil pagar por você mesmo e poder usar isso como uma nova estrelinha em seu currículo.
Até mais!

Já escrevi um post que descreve os passos de como criar um driver bem simples. Este driver simplesmente mantém uma lista de strings que recebe via IRP’s de escrita e as devolve nas IRP’s de leitura. Muito bem, se você ainda não sabe o que é uma IRP, um outro post tenta explicar o que são as IRP’s e até descreve os passos necessários para utilizar o IRP Tracker para observar as IRP’s indo e vindo. Se fizermos um pequeno teste utilizando o IRP Tracker sobre o driver de exemplo que acabei de comentar, teremos uma saída semelhante a figura abaixo.

Podemos ver as todas as IRP’s que nosso device recebeu desde a IRP_MJ_CREATE até a IRP_MJ_CLOSE. Entre estas IRP’s notamos que algumas delas não foram completadas com sucesso. Como nenhuma rotina foi designada para tratar IRP_MJ_CLEANUP, estas IRP’s são terminam com STATUS_INVALID_DEVICE_REQUEST. Neste post vou comentar um pouco sobre a esta IRP e como seu device interage com os processos que obtiveram um handle para ele.

Para ver detalhes da IRP, dê um duplo clique sobre a linha da IRP no IRP Tracker para que a janela abaixo seja exibida. Nessa janela é possível ver, entre outros detalhes, o FileObject utilizado na IRP. Isso nos será útil neste post durante os testes.

Quando o IRP_MJ_CLEANUP ocorre?

O Object Manager envia uma IRP de CLEANUP a fim de notificar o driver de que o último handle para determinado FileObject foi fechado. Como alguns de vocês devem saber, quando uma aplicação usa o CreateFile para obter um handle para nosso device, isso resulta na criação de um FileObject. As operações subseqüentes utilizando este handle estarão vinculadas a este FileObject. Mais detalhes sobre isso neste post.

Um FileObject não tem uma relação direta com um handle. Um handle pode ser duplicado ou mesmo herdado do processo pai na criação de um novo processo. O resultado destas ações é ter vários handles que serão traduzidos para o mesmo FileObject. Desta forma, nem sempre quando uma aplicação chama a função CloseHandle, uma IRP de CLEANUP ou CLOSE é enviada ao driver.

Para acompanhar os passos abaixo, o código fonte do programa de exemplo está disponível para download ao final deste post. Este programa utiliza o driver de exemplo construído em outro post, o código fonte do driver pode ser baixado daqui. A partir dos fontes você pode compilar e instalar o driver de teste. Se você não sabe como fazer isso, este post pode te ajudar. Depois de instalar o driver de teste, seria interessante poder executar as chamadas abaixo com a ajuda de um depurador, e assim, poder observar os resultados no IRP Tracker a cada linha executada.

É importante ler os comentários do fonte abaixo. Fiquei com preguiça de duplicar essas informações aqui no post.

/****

***     main

**

**      Espero que todos saibam que este é o ponto

**      de entrada de uma aplicação. Caso contrário,

**      você pode estar se preciptando em ler um blog

**      de driver para Windows.

*/

int main(int argc, char* argv[])

{

    HANDLE  h1, h3, h3;

    CHAR    szBuffer[100];

    DWORD   dwBytes;

    //-f--> Aqui estamos abrindo o primeiro handle

    //      para o nosso device. Este é o passo 1

    //      no IRP Tracker. Verifique o valor do

    //      FileObject para poder comparar em operações

    //      futuras.

    h1 = CreateFile("\\\\.\\EchoDevice",

                    GENERIC_ALL,

                    0,

                    NULL,

                    OPEN_EXISTING,

                    0,

                    NULL);

    //-f--> Aqui estamos abrindo o segundo handle

    //      para o nosso device. Este é o passo 2

    //      no IRP Tracker. Verifique o valor do

    //      FileObject para poder comparar em operações

    //      futuras.

    h3 = CreateFile("\\\\.\\EchoDevice",

                    GENERIC_ALL,

                    0,

                    NULL,

                    OPEN_EXISTING,

                    0,

                    NULL);

    //-f--> Aqui lançaremos uma IRP_MJ_READ para o

    //      primeiro FileObject obtido. Passo 3 no

    //      IRP Tracker. Note que o primeiro FileObject

    //      é utilizado nesta IRP.

    ReadFile(h1,

             szBuffer,

             sizeof(szBuffer),

             &dwBytes,

             NULL);

    //-f--> Aqui lançaremos uma IRP_MJ_READ para o

    //      segundo FileObject obtido. Passo 4 no

    //      IRP Tracker. Note que o segundo FileObject

    //      é utilizado nesta IRP.

    ReadFile(h3,

             szBuffer,

             sizeof(szBuffer),

             &dwBytes,

             NULL);

    //-f--> A duplicação de handle não é notificada

    //      ao driver. Apenas o Object Manager sabe

    //      disso. Não existe nenhum passo correspondente

    //      no IRP Tracker.

    DuplicateHandle(GetCurrentProcess(),

                    h1,

                    GetCurrentProcess(),

                    &h3,

                    0,

                    FALSE,

                    DUPLICATE_SAME_ACCESS);

    //-f--> Como o terceiro handle foi obtido atravéz de

    //      uma duplicação do primeiro, o FileObject

    //      correspondente é o mesmo do primeiro handle.

    //      Passo 5 no IRP Tracker. Note que o primeiro

    //      FileObject é utilizado nesta IRP.

    ReadFile(h3,

             szBuffer,

             sizeof(szBuffer),

             &dwBytes,

             NULL);

    //-f--> Como temos dois handles para o primeiro FileObject,

    //      fechar um deles não implicará em nenhuma notificação

    //      ao nosso device. Não existe passo correspondente no

    //      IRP Tracker.

    CloseHandle(h1);

    //-f--> Este handle não foi duplicado, assim, quando o fecharmos,

    //      uma IRP_MJ_CLEANUP seguido de uma IRP_MJ_CLOSE serão

    //      enviadas ao driver. Passo 6 no IRP Tracker.

    CloseHandle(h3);

    //-f--> Fechando este handle, teremos o mesmo comportamento

    //      observado no fechamento do handle h3. Do ponto de

    //      vista do driver, o primeiro FileObject será destruído

    //      agora. Passo 7 no IRP Tracker.

    CloseHandle(h3);

    //-f--> E todos viveram felizes para sempre.

    return 0;

}

Obter um handle para um objeto nos assegura que este objeto será válido enquanto não fecharmos o handle. Um objeto só pode ser destruído pelo sistema depois que todos os handles para ele forem fechados. Para isso, o Object Manager mantém dois contadores, o ProcessHandleCount e o SystemHandleCount. O primeiro deles mantém a quantidade de handles abertos para um objeto em um determinado processo. O outro mantém a soma de todos os ProcessHandleCount para o objeto no sistema. Estes contadores são decrementados à medida que os handles são fechados. Quando chegam a zero, uma IRP_MJ_CLEANUP é gerada.

Normalmente a IRP_MJ_CLEANUP nos serve como evento para cancelar qualquer operação assincrona relativa ao FileObject que está sendo finalizado. IRP’s são ligadas às threads que às lançaram e qualquer IRP assincrona deveria ser devidamente cancelada neste momento.

Então para quê serve o IRP_MJ_CLOSE?

Além dos contadores de referência acima citados, existe também o ObjectReferenceCount, que além de ser incrementado quando um novo handle é obtido, também é incrementado quando uma referência de kernel é feita utilizando funções do tipo ObReferenceObject por exemplo. Estas chamadas incrementam o ObjectReferenceCount sem que um novo handle seja gerado. Para quem conhece COM, esta chamada tem o comportamento semelhante ao AddRef. Isso permite que o objeto se mantenha válido para o kernel, mesmo depois que todos os handles para ele foram destruídos. Enfim, quando este contador chegar a zero, então a IRP_MJ_CLOSE é enviada.

Um driver pode associar estruturas de dados a um determinado FileObject utilizando os pointeiros FsContext e FsContext2 conforme eu já comentei neste outro post. Estas estruturas só poderão ser desalocadas quando recebermos o IRP_MJ_CLOSE.

Operações após o IRP_MJ_CLEANUP

Quando recebemos uma IRP_MJ_CLEANUP, não significa que o fim está próximo. Outros componentes do kernel podem lançar novas IRP’s de leitura ou escrita mesmo depois deste evento. Sem falar das IRP_MJ_INTERNAL_DEVICE_CONTROL que podem ser trocadas entre drivers.

Um cenário muito comum no desenvolvimento de File Systems é justamente quando uma refêrencia de um FileObject que é mantida pelo Cache Manager. Mesmo quando todos os handles forem fechados pelas aplicações, o sistema ainda retém esta refêrencia antecipando que alguma aplicação pode querer abrir o mesmo arquivo novamente. O Cache Manager possui system threads que realizam a então chamada “Escrita retardada”. Este recurso concentra várias escritas a um arquivo em uma única operação posterior a fim de diminuir o número de acessos a disco, assim ganhando performance. É muito comum tais escritas serem realizadas depois que o arquivo teve todos os seus handles fechados por aplicações, e assim temos escritas depois do IRP_MJ_CLEANUP.

No final de tudo isso, espero mais uma vez ter mais ajudado que atrapalhado. Assuntos referentes a Cache Manager, Memory Manager e File Systems não são muito triviais, mas são interessantes o suficiente para ler a respeito e entender o que o sistema faz antes de falar que tudo é uma porcaria.

Até a próxima!

TestCleanup.zip

Antes de completar três meses sem qualquer sinal de vida, aqui estou a dar uma espiada no que ocorre na blogosfera. Este final de ano foi realmente corrido. Como já devem saber, minha ida para IBM contribuiu um pouco para esta minha ausência. Tudo bem, a faculdade também ajudou bastante, no finalzinho do ano reservei um tempo para mim mesmo e fui dar uma passeada na praia. Mas vamos deixar de conversa mole e ir ao que interessa.

Neste post, de volta ao mundo dos vivos, vou comentar apenas pequenas coisas e deixar para depois (mas ainda para esta vida) um post mais elaborado, como os que vocês estão acostumados a ver por aqui.

Debug em Free

Uma das coisas que tive que aprender a conviver na IBM é a depurar o driver que escrevemos sempre com o Build Free, ou seja, com otimizações e tudo mais que uma compilação release merece. Eu bem que tentei relutar dizendo que é importante que tenhamos uma versão checked para testes e que seria valioso poder rodar nosso driver com todos os ASSERT‘s ligados e verificando qualquer coisa fora do normal que possa ocorrer. Mas acreditem, não é fácil convencer este povo que entre Indianos e Norte-Americanos já estão acostumados com essa situação. Foi procurando boas justificativas para termos uma versão checked utilizável que encontrei este post. Pois é, as justificativas são realmente muito boas, mas ainda defendo que deveriamos ter uma versão checked. Estou preparando um post que fala um pouco sobre isso.

Por falar em saber inglês

Alguns posts antes deste, eu falei do MSDN traduzido para algumas linguas, incluindo o português. O recado foi que, dá pra se virar um pouquinho sem saber inglês, mas se você ainda não sabe e pretende desenvolver drivers para viver, então trate de aprender o quanto antes. Me lembrei deste post hoje quando numa pesquisa do Google um link foi especialmente gratificante.

Dicas do IoGetDeviceObjectPointer

Bom, se alguém conseguiu pegar alguma dica, por favor me passe. Se um dia eu resolver aprender uma terceira lingua, agora já tenho uma candidata.

Ano novo cara nova

Era para ter acontecido antes, mas infelizmente o tempo é curto para muitas pessoas. Coloquei em prova as habilidades de web designer do meu irmão para dar um tapa no layout do meu blog. Está ficando muito bom, mas ainda não tenho nada de concreto para mostrar. Estarei migrando para o WordPress em pouco tempo. Uma boa parte do trabalho já foi feito, mas ainda há muito a ser feito. Minha principal intenção em migrar para o WordPress é poder utilizar um destes plug-ins que permitem que eu tenha o mesmo post tanto em inglês como em português. Bom, um dos poucos que testamos ainda deu problema. Mas vamos chegar lá.

Até mais mais…

Depois de alguns meses em um longo processo seletivo, finalmente já posso compartilhar essa boa notícia com vocês. Boa notícia para mim pelo menos. Hoje, dia 15 de outubro 2007 foi meu primeiro dia como IBMista no prédio da rua Tutóia. Não, eu não desisti do Kernel do Windows para programar Java nem vou programar ABAP. O negócio é o de sempre, tela azul mesmo.

Como você aprendeu isso?

Essa é uma pergunta que várias pessoas já me fizeram. Parece brincadeira, mas parece que as coisas têm contribuído naturalmente para o meu desenvolvimento profissional como programador Kernel para Windows. Quando eu era estagiário na Provectus, comecei a ler o livro “Desvendando o Windows NT” por puro hobby, sem a menor esperança de um dia poder trabalhar com as coisas abordadas por aquela literatura, afinal de contas, ter o privilégio de trabalhar em uma empresa de desenvolvimento de hardware no Brasil seria como ganhar na loteria. Bom, meu estágio como programador C foi em uma empresa que desenvolvia seu próprio hardware. Sorte talvez. Quando menos esperei, lá estava eu programando serviços para Windows NT, utilizando memória compartilhada e até um device driver apareceu pra eu dar uma olhada. Como eu já sabia alguma coisa de MFC e Win32 API, o que me atraía mesmo era o desenvolvimento em Kernel Mode. Mais uma vez por hobby, comecei a ler a respeito, sem esperanças devo dizer, apenas por prazer mesmo. É, desta vez o resultado foi contrário e fui trabalhar em uma empresa de compra e venda de ações da bolsa de valores para desenvolver compotentes COM+ em c++. Um ano foi o bastante para aprender o suficiente de ASP, SQL e Java para saber que não era aquilo que eu queria para mim. Felizmente o destino me trouxe a SCUA. Eu nem sabia que eles faziam drivers para Windows. Foi durante uma entrevista para fazer parte do time de aplicações que descobri que havia um time de drivers. Enfim, adivinha em qual time fui parar depois de um tempo. Lá tive contato com profissionais da área, muitos livros, listas de discussão e principalmente a oportunidade de por em prática o que eu aprendia nos livros. Depois veio a Tempest e com ela as chances de fazer um treinamento de File System Drivers em uma das maiores autoridades no assunto. Em seguida um amigo me indicou na IBM, e depois de duas entrevistas no prédio da rua Tutóia e uma entrevista técnica por telefone com o time dos Estados Unidos, bem aqui estou eu. Vou trabalhar no time de desenvolvimento do MVFS para Windows.

Um dos pontos que mais me anima nesta nova empreitada é a oportunidade de trabalhar com pessoas altamente qualificadas no assunto e poder aprender muito com um time que envolve minimamente americanos, indianos, e agora mais um brasileiro.

Meu primeiro dia de IBM foi cheio de palestras. Inicialmente sobre a história da IBM, e as outras foram mais sobre os vários procedimentos internos que uma empresa deste porte exige.

Inté mais…