Levando a tela azul pra casa
Nada melhor que uma bela choraderia para começar este post. Meu rítmo está baixo por conta da universidade estar sugando todas as minhas energias vitais. Se você tem acompanhado meu blog nos últimos posts, já sabe do que estou falando. No meu tempo livre estive correndo com meu projeto, meu estágio e meu emprego. Meu blog também participa dessa lista de tarefas, mas o coitadinho tem menos prioridade aqui. Alguns de vocês devem saber que sou helimodelista por hobby, mas como eu disse ao meu amigo Heldai outro dia: "Hobby é o nome que se dá àquilo que fazemos para ocupar o tempo que temos livre, mas ainda estou para descobrir o nome que daríamos àquilo que gostaríamos de fazer se tivéssemos tempo livre...". Enfim, como isso não tem nada a ver com o post de hoje, vamos mudar de assunto. Entre uma coisa e outra, estive tentando pensar em algo simples para um post pequeno. Foi então que a dúvida do leitor Ismael Rocha (Brasília - DF) gerou este post. "Existe uma maneira de salvar as BSOD's para posteriormente verificar eventuais problemas?" Salvar uma tela azul? Salvar o quê? A máquina já morreu meu amigo! Já era! Acabou! O que você ainda pode tentar salvar é seu emprego.
Brincadeiras à parte, existe sim.
O sistema operacional está pré-configurado para reiniciar automagicamente quando uma falha crítica acontece. Falha crítica é a maneira polida de se dizer que a casa caiu, a vaca foi pro brejo, o jacaré te abraçou, o tambor girou, o ferro berrou, o tempo fechou, ficou pequeno pra você... enfim, uma tela azul aconteceu. Não que eu não goste de telas azuis, mas do efeito colateral que ela nos traz. Pela norma mundial dos consumidores de drivers de terceiros, se você é o autor de um driver que estiver instalado em uma máquina no momento da falha, esteja ele rodando ou não, então a culpa da falha é sua até que se prove o contrário. É triste, mas é a realidade. A partir do momento que uma tela azul acontece, você é o culpado padrão e terá que ficar aguentando piadinhas pelo resto da eternidade. Gostaria de aproveitar o contexto para mandar um abraço pro meu amigo Heldai.
Exibindo a tela azul
Na tentativa de salvar sua dignidade, você tenta provar que a culpa não é sua. Dizer que o reset da máquina é uma feature do seu driver e que felizmente funcionou muito bem não vai colar, não na segunda vez. Mas o que você pode fazer se a tela azul é apenas um flash de informações enquanto a máquina não reinicia? Felizmente você pode mudar isso. Clicando com o botão direito do mouse sobre o "Meu computador", selecionando "Propriedades". Daí em diante é só dar uma olhada na figura abaixo para descobrir que você pode evitar que a máquina reinicie automaginamente. Você terá de desmarcar a opção "Reiniciar automaticamente", e assim ter todo o tempo que for necessário para mostrar a todos que o problema não é seu. Na maioria das vezes o sistema consegue detectar o driver que provavelmente é o causador de toda essa dor de cabeça e exibir o nome do arquivo na tela azul como podemos ver na figura abaixo.
Desmontando uma tela azul
"Nossa! Então o Windows tem um algorítmo de inteligência artificial, que provalvelmente usa nanotecnologia de alguma forma para descobrir o driver culpado?" Na verdade é um pouco mais simples que isso, o Windows simplesmemte pega a imagem do driver que lançou uma exceção que não foi manipulada ou que voluntariamente derrubou o sistema por detectar alguma incoerência. Por isso, nem sempre o nome do driver exibido é de fato o nome do driver culpado. Se pensarmos no simples exemplo onde o driver MetralhadoraGiratoria.sys escreve onde não deveria corrompendo algum Pool de alocações, esse erro mais tarde pode ser detectado pelo driver Laranja.sys que, na hora de fazer uma alocação de memória, chama uma rotina de sistema que por sua vez chama a rotina KeBugCheckEx() ao detectar tal incoerência. Consegue adivinhar o nome do driver que aparecerá no BO? Outras informações ainda podem ser obtidas da tela azul. Se é o nome do seu driver que aparece na tela, então você ainda pode obter o endereço da instrução onde a desgraça ocorreu. Em nosso exemplo o endereço é o 0xF8DD8A415 partir daí podemos chegar na função que estava sendo executada no momento da falha se tivermos o arquivo de mapa gerado pelo linker. Também é possível obter a data da imagem do arquivo e tirar aquela dúvida de que realmente era a versão certa que estava sendo executada. A data do arquivo é obtida no campo DateStamp e é expressa em um valor hexadecimal de 32 bits representando a quantidade de segundos deste meia noite de primeiro de Janeiro de 1970. Difícil mesmo é achar alguém com paciência suficiente para calcular isso diante de uma tela azul. Existem meios bem menos trabalhosos de descobrir que a culpa foi sua mesmo. Na minha opinião, a informação mais relevante que a tela azul oferece é o Stop Code. Como o nome já sugere, Stop Code é um código que vai indicar o motivo da falha do sistema. você pode consultar a lista de Stop Codes neste link ou ainda dar uma olhada no arquivo C:\WinDDK\6001.18002\inc\api\BugCodes.h que vem no WDK. Stop Codes vêm com até quatro parâmetros que trazem informações adicionais ao código de parada. A interpretação destes valores dependerá do código de falha, que em nosso exemplo é 0x7E. Consultando no link que informei a pouco, teremos a seguinte interpretação para os valores que nos foi apresentado.
Mas existe um jeito de salvar a BSOD ou não?
Tá tá tá... É que começo a escrever e acabo me empolgando. Mas enfim, quando uma falha crítica ocorre, o sistema cria um arquivo conhecido como Crash Dump. Existem três opções de crash dumps que podem ser geradas. Dump Completo: Nesta opção, todo o conteúdo da memória física no momento da falha será copiado em um arquivo. Obviamente o tamanho deste arquivo será a quantidade de memória presente na máquina com um acréssimo de 1MB de header. Essa opção não aparece nas máquinas que possuam mais de 2GB de memória física, mas ainda é possivel configurar o dump completo sem utilizar essa interface gráfica escrevendo diretamente no registro. Esse método é também conhecido como "configurar na unha". O dump completo é muito útil quando a informação presente em páginas de memória em User Space for relevante para o problema, tal como situações de Dead Locks. Se você não sabe o que significa User Space, este post pode ajudar. Dump de Kernel: Aqui somente as páginas em System Space serão copiadas para disco. O tamanho deste arquivo vai variar dependendo de quantidade de memória física a máquina tem instalada, mas não existe uma proporção exata. Muito do balanceamento de páginas utilizado pelo gerenciador de memória virtual vai determinar o tamanho deste arquivo, mas ele fica pela ordem de 200MB num sistema com 4GB de memória total (já dá pra levar no pen drive). Essa opção é normalmente a mais viável, já que só carrega a informação mais relevante para um crash de sistema. Dump Mínimo: Aqui um arquivo de 64KB será gerado para sistemas 32 bits ( 128KB para sistemas 64 bits). Neste arquivo temos apenas o Stop Code e seus parâmetros, a lista de drivers carregados no momento da falha, informações sobre o processo e thread corrente e o Call Stack da thread que causou a falha.
Na mesma janela onde você configura o reinicio automático do sistema, existem dois outros campos que vão configurar o tipo de dump desejado e o caminho onde este será gerado. Agora você já pode levar sua tela azul no coração e depurar onde você quiser. Em casa, no trabalho, no trêm, no metrô... Você pode ainda pedir que clientes enviem seus crash dumps para que você possa diagnosticar o problema ser ter que se deslocar através de rios e montanhas sob o frio e a chuva.
Tenho o Crash Dump, e agora?
Agora que você é um feliz proprietário de um maravilhoso arquivo de Crash Dump, o que mais você poderia querer da vida? Talvez ser capaz descobrir a causa do problema já seria um bom começo. Para isso vamos utilizar o depurador nativo do sistema operacional. Se você ainda não conhece o WinDbg, então dê uma olhada neste post para que você sabia do que estamos falando aqui. Admitindo que você tenha Windbg instalado em sua máquina de desenvolvimento, e que este esteja com o servidor de símbolos configurado, tudo que temos a fazer agora é abrir o WinDbg, selecionar o ítem "Open Crash Dump..." no menu "File" e apontar o caminho do arquivo de dump que você copiou da pobre máquina que ousou rodar seu driver. O texto abaixo é o resultado exibido na janela de comandos quando o Crash Dump é aberto. Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [Z:\Sources\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available Symbol search path is: srv* Executable search path is: Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp.080413-2111 Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x80553fc0 Debug session time: Thu Jun 18 14:46:24.969 2009 (GMT-3) System Uptime: 0 days 0:03:20.375 Loading Kernel Symbols ............................................................... ......................................................... Loading User Symbols Loading unloaded module list ........... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7E, {c0000005, f8d9f415, f8af1bb4, f8af18b0} Probably caused by : Useless.sys ( Useless!DriverEntry+5 ) Followup: MachineOwner ---------
Agora se simplesmente executarmos o comando sugerido, já teremos uma boa descrição do que aconteceu com máquina que sofreu a falha crítica. kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: f8d9f415, The address that the exception occurred at Arg3: f8af1bb4, Exception Record Address Arg4: f8af18b0, Context Record Address Debugging Details: ------------------ EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: Useless!DriverEntry+5 [z:\sources\driverentry\useless\useless.c @ 7] f8d9f415 c7050000000000000000 mov dword ptr ds:[0],0 EXCEPTION_RECORD: f8af1bb4 -- (.exr 0xfffffffff8af1bb4) ExceptionAddress: f8d9f415 (Useless!DriverEntry+0x00000005) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000000 Attempt to write to address 00000000 CONTEXT: f8af18b0 -- (.cxr 0xfffffffff8af18b0) eax=07263867 ebx=00000000 ecx=bb40e64e edx=1be10003 esi=e19feea8 edi=81eb41d0 eip=f8d9f415 esp=f8af1c7c ebp=f8af1c7c iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 Useless!DriverEntry+0x5: f8d9f415 c7050000000000000000 mov dword ptr ds:[0],0 ds:0023:00000000=???????? Resetting default scope PROCESS_NAME: System ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000001 EXCEPTION_PARAMETER2: 00000000 WRITE_ADDRESS: 00000000 FOLLOWUP_IP: Useless!DriverEntry+5 [z:\sources\driverentry\useless\useless.c @ 7] f8d9f415 c7050000000000000000 mov dword ptr ds:[0],0 BUGCHECK_STR: 0x7E DEFAULT_BUCKET_ID: NULL_DEREFERENCE LAST_CONTROL_TRANSFER: from 8057677f to f8d9f415 STACK_TEXT: f8af1c7c 8057677f 81eb41d0 81d46000 00000000 Useless!DriverEntry+0x5 [z:\sources\driverentry\useless\useless.c @ 7] f8af1d4c 8057688f 80000360 00000001 00000000 nt!IopLoadDriver+0x66d f8af1d74 80534c02 80000360 00000000 823c68b8 nt!IopLoadUnloadDriver+0x45 f8af1dac 805c6160 b29accf4 00000000 00000000 nt!ExpWorkerThread+0x100 f8af1ddc 80541dd2 80534b02 00000001 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 FAULTING_SOURCE_CODE: 3: NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, 4: IN PUNICODE_STRING pusRegistryPath) 5: { 6: //-f--> Diga olá à BSOD e vá se acostumando com ela... > 7: *(PVOID*)0x00000000 = 0; 8: 9: //-f--> Não vamos viver para ver isso. 10: return STATUS_SUCCESS; 11: } SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: Useless!DriverEntry+5 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Useless IMAGE_NAME: Useless.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4a3844ef STACK_COMMAND: .cxr 0xfffffffff8af18b0 ; kb FAILURE_BUCKET_ID: 0x7E_Useless!DriverEntry+5 BUCKET_ID: 0x7E_Useless!DriverEntry+5 Followup: MachineOwner ---------
Se a máquina que está abrindo o arquivo de dump for a máquina de desenvolvimento do seu driver, o Windbg será capaz de automagicamente achar os fontes do seu driver e apontar a causa da falha com grandes detalhes. Então certifique-se que seu gerente não esteja por perto nesse momento. Isso já é muito mais informação do que você poderia obter simplesmente olhando para a tela azul do computador. Neste exemplo utilizei o driver de exemplo do post Getting Started para reproduzir a tela azul. Mas não se preocupe com isso, mesmo sendo um programador novato em drivers, uma das primeiras coisas que você aprenderá é como gerar telas azuis. Mais uma vez espero ter ajudado.
Have fun!
Enumerando dispositivos
Dentre minhas tarefas atuais, estava a de ler as amostras de um giroscópio utilizando uma porta serial e gerar um arquivo com elas. Este arquivo seria lido por um driver semelhante ao demonstrado no post anterior a este. No datasheet do giroscópio há uma descrição do protocolo, sem falar do exemplo feito em Visual Basic que existe no site do fabricante, que demonstra a aceleração angular em cada eixo bem como as acelerações lineares deles como mostra abaixo. Toda a interface de configuração e obtenção dos dados do giroscópio é realizada através da serial. Mesmo sem uma aplicação dedicada pode-se utilizar um programa qualquer, como o HyperTerminal, para ter acesso aos menus oferecidos pelo dispositivo. Utilizando uma porta serial, qualquer kit de microcontrolador que não tenha display e nem mesmo um teclado pode oferecer uma interface bem amigável. Escrever protocolos seriais não é algo que me assuste. Duro é ter que lembrar como programar uma aplicação User-Mode que tenha janelas, botões e outros controles, mas nada que um pouco de MSDN não resolva. Programadores de drivers normalmente testam tudo que podem utilizando aplicações console, então desenvolvi um pequeno software de terminal para lidar diretamente com o dispositivo. O fonte dele segue abaixo e fica de brinde para quem precisar brincar com portas seriais qualquer dia.
int _tmain(int argc, _TCHAR* argv[])
{
DWORD dwBytes,
dwError = ERROR_SUCCESS;
HANDLE hCom;
ULONG i;
UCHAR ucByteIn[512], ucByteOut;
DCB dcb;
COMMTIMEOUTS CommTimeouts;
hCom = CreateFile(L"COM3",
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hCom == INVALID_HANDLE_VALUE)
{
dwError = GetLastError();
printf("CreateFile failed with error %d.\n",
dwError);
return dwError;
}
if (!GetCommState(hCom, &dcb))
{
dwError = GetLastError();
printf ("GetCommState failed with error %d.\n",
dwError);
CloseHandle(hCom);
return dwError;
}
dcb.DCBlength = sizeof(DCB);
dcb.BaudRate = CBR_57600;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
dcb.fDtrControl = DTR_CONTROL_DISABLE;
dcb.fRtsControl = RTS_CONTROL_DISABLE;
if (!SetCommState(hCom, &dcb))
{
dwError = GetLastError();
printf ("SetCommState failed with error %d.\n",
dwError);
CloseHandle(hCom);
return dwError;
}
CommTimeouts.ReadIntervalTimeout = 0;
CommTimeouts.ReadTotalTimeoutMultiplier = 0;
CommTimeouts.ReadTotalTimeoutConstant = 100;
CommTimeouts.WriteTotalTimeoutConstant = 0;
CommTimeouts.WriteTotalTimeoutMultiplier = 0;
if (!SetCommTimeouts(hCom, &CommTimeouts))
{
dwError = GetLastError();
printf ("SetCommTimeouts failed with error %d.\n",
dwError);
CloseHandle(hCom);
return dwError;
}
while(1)
{
if (_kbhit())
{
ucByteOut = _getch();
if (ucByteOut == 27)
break;
if (!WriteFile(hCom,
&ucByteOut,
1,
&dwBytes,
NULL))
{
dwError = GetLastError();
break;
}
}
if (!ReadFile(hCom,
ucByteIn,
sizeof(ucByteIn),
&dwBytes,
NULL))
{
dwError = GetLastError();
break;
}
for (i=0; i<dwBytes; i++)
{
if (ucByteIn[i] == 0x0d)
puts("");
else
printf("%c", ucByteIn[i]);
}
}
CloseHandle(hCom);
return dwError;
}Abrir uma porta serial é a parte mais simples desta história, o problema é decidir qual porta abrir. Como qualquer programa decente, deveria haver um combo list com as portas seriais disponíveis no computador, onde o usuário escolheria uma e pronto. A partir daí é só obter a porta selecionada pelo usuário e montar uma chamada para a rotina CreateFile() como ilustrado no cógido acima. Tudo bem, arrastei o controle para a janela que eu estava programando e agora é só preenchê-lo. Então pensei: "Deve haver alguma função do tipo EnumerateCommPorts() na API", mas não foi o que a página da referência me mostrava. - Como assim não tem? O Google deve saber algo a respeito. - Acabei descobrindo que esta é uma dúvida bem comum por aí. Uns resolvem este problema fazendo um loop que tenta abrir as portas seriais em sequência (COM1, COM2,... ), outros utilizam a função QueryDosDevice() e filtram os Symbolic Links que iniciam com "COM(n)", mas o método que vou mostrar aqui é capaz de enumerar qualquer tipo de interface utilizando a SetupAPI.
Setup quem?
A SetuAPI é uma parte do Plug-And-Play que fornece serviços às aplicações User-Mode. O Plug-And-Play tem como um dos seus objetivos, unificar a configuração, uso e a enumeração de dispositivos e serviços semelhantes. Desta forma todos os fabricantes de placas que oferecem serviços de porta serial podem ter seus dispositivos configurados de uma única maneira. Dispositivos que oferecem serviços de porta serial devem implementar uma interface pré-definida, ou seja, devem se mostrar dispostos a receber IOCTLs e responder a eles de maneira prevista na documentação. O driver que desejar criar devices que implementem a interface de porta serial deverá declarar isso através da chamada à rotina IoRegisterDeviceInterface(). Aqui um device é associado à uma classe de interface de dispositivo, a qual é identificada por um GUID. Existem diversas classes de interfaces de dispositivos pré-definidas no sistema, como listado aqui, e a classe de portas seriais é uma delas. A partir daí, seu device será enumerado por rotinas do Plug-and-Play como provedor de uma determinada interface. Então tá. O que temos que fazer é utilizar estas funções de enumeração de interfaces para descobrir quais os dispositivos que implementam a interface de porta serial. A SetupAPI vai nos ajudar com essa tarefa. Mas antes de darmos uma olhada no fonte, vamos resolver uma coisinha. Tenho visto diferentes maneiras de usar GUID_DEVINTERFACE_COMPORT, uns incluem o header de Kernel-Mode Ntddser.h, outros definem o GUID na unha, mas qual seria o jeito correto?
Definindo o GUID de interface
Tudo começa com a chamada à rotina SetupDiGetClassDevs() que vai reunir informações sobre o grupo de dispositivos que correspondem aos critérios de busca adotados nos parâmetros. Vamos querer dispositivos que implementem a interface identificada por GUID_DEVINTERFACE_COMPORT, mas se simplesmente fizermos a chamada como mostra abaixo obteremos o erro exibido em seguida. hDevInfoSet = SetupDiGetClassDevs(&GUID_DEVINTERFACE_COMPORT,
NULL,
NULL,
DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);1>z:\sources\samples\enumserialport.obj : error LNK2001: unresolved external
symbol _GUID_DEVINTERFACE_COMPORT Isso ocorre porque GUID_DEVINTERFACE_COMPORT está declarado em WinIoCtl.h. Lembre-se que este header é indiretamente incluído por Windows.h quando o símbolo WIN32_LEAN_AND_MEAN não é definido, como já comentei neste outro post. Mas mesmo incluindo este header ainda temos o mesmo problema. Vamos olhar isso um pouco mais de perto. No header WinIoCtl.h temos: DEFINE_GUID(GUID_DEVINTERFACE_COMPORT, 0x86e0d1e0L, 0x8089, 0x11d0,
0x9c, 0xe4, 0x08, 0x00, 0x3e, 0x30, 0x1f, 0x73);Mas o que é DEFINE_GUID afinal? Em GuidDef.h temos: #ifdef INITGUID
#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
EXTERN_C const GUID DECLSPEC_SELECTANY name \
= { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
#else
#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
EXTERN_C const GUID FAR name
#endif Então agora nos vem o sonoro "Aaaah táaa!". GUID_DEVINTERFACE_COMPORT é uma constante que é definida quando o símbolo INITGUID é definido, caso contrário, esta constante é apenas declarada. O símbolo INITGUID é definido no header InitGuid.h. Assim, quando você quiser utilizar os GUIDs declarados com DEFINE_GUID, você terá que em um dos seus módulos incluir o header Initguid.h antes de Windows.h. Como nosso exemplo só tem um módulo, então fica fácil. Como de costume, todo código fonte está contido num exemplo disponível para download. #include <InitGuid.h>
#include <Windows.h>
#include <SetupApi.h>
Enumerando interfaces
DWORD EnumSerialInterfaces(void)
{
CHAR szFriendlyName[100];
HDEVINFO hDevInfoSet = NULL;
SP_DEVICE_INTERFACE_DATA DevInterfaceData;
SP_DEVINFO_DATA DevInfoData;
DWORD dwReturn,
dwInterfaceIndex = 0;
try
{
hDevInfoSet = SetupDiGetClassDevs(&GUID_DEVINTERFACE_COMPORT,
NULL,
NULL,
DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (hDevInfoSet == INVALID_HANDLE_VALUE)
throw GetLastError();
DevInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
while (SetupDiEnumDeviceInterfaces(hDevInfoSet,
0,
&GUID_DEVINTERFACE_COMPORT,
dwInterfaceIndex++,
&DevInterfaceData))
{
DevInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
if (SetupDiGetDeviceInterfaceDetail(hDevInfoSet,
&DevInterfaceData,
NULL,
0,
NULL,
&DevInfoData))
throw GetLastError();
if (!SetupDiGetDeviceRegistryProperty(hDevInfoSet,
&DevInfoData,
SPDRP_FRIENDLYNAME,
NULL,
(PBYTE)szFriendlyName,
sizeof(szFriendlyName),
NULL))
throw GetLastError();
printf("%d) %s\n",
dwInterfaceIndex,
szFriendlyName);
}
}
catch(DWORD dwError)
{
printf("Error %d on trying enumerate device interfaces.\n",
dwError);
dwReturn = dwError;
}
if (hDevInfoSet)
SetupDiDestroyDeviceInfoList(hDevInfoSet);
return dwReturn;
}Com essa implementação, teremos a seguinte saída.
Legal, mas não era bem isso...
Muito bem. As portas foram enumeradas, mas como eu passaria uma string dessas para a função CreateFile()? Terei que ficar interpretando essa string para pegar a parte "COM1" que está entre parênteses? Na verdade existem meios de você obter o Symbolic Link dos dispositivos também utilizando funções da SetupAPI, mas eu imagino que o que você queria é o mesmo que eu quero. Preencher um Combo Box com o nome simples das portas seriais, como qualquer programa normal. O port name, que é a string "COMx" que estamos procurando, está escrito como um valor de registro na chave do dispotivo. Todo driver de porta serial tem que ter esse valor conforme mostra esta página. Para obter a chave de registro referente ao dispositivo, utilizaremos uma outra rotina da SetupAPI. O fonte abaixo vai enumerar as portas seriais da maneira que estamos querendo.
DWORD EnumSerialPorts(void)
{
CHAR szPortName[10];
HDEVINFO hDevInfoSet = NULL;
SP_DEVICE_INTERFACE_DATA DevInterfaceData;
SP_DEVINFO_DATA DevInfoData;
DWORD dwReturn,
dwSize,
dwInterfaceIndex = 0;
HKEY hKey;
try
{
hDevInfoSet = SetupDiGetClassDevs(&GUID_DEVINTERFACE_COMPORT,
NULL,
NULL,
DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if (hDevInfoSet == INVALID_HANDLE_VALUE)
throw GetLastError();
DevInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
while (SetupDiEnumDeviceInterfaces(hDevInfoSet,
0,
&GUID_DEVINTERFACE_COMPORT,
dwInterfaceIndex++,
&DevInterfaceData))
{
DevInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
if (SetupDiGetDeviceInterfaceDetail(hDevInfoSet,
&DevInterfaceData,
NULL,
0,
NULL,
&DevInfoData))
throw GetLastError();
hKey = SetupDiOpenDevRegKey(hDevInfoSet,
&DevInfoData,
DICS_FLAG_GLOBAL,
0,
DIREG_DEV,
KEY_QUERY_VALUE);
if (hKey == INVALID_HANDLE_VALUE)
throw GetLastError();
dwSize = sizeof(szPortName);
dwReturn = RegQueryValueEx(hKey,
"PortName",
NULL,
NULL,
(LPBYTE)szPortName,
&dwSize);
RegCloseKey(hKey);
if (dwReturn != ERROR_SUCCESS)
throw dwReturn;
printf("%d) %s\n",
dwInterfaceIndex,
szPortName);
}
}
catch(DWORD dwError)
{
printf("Error %d on trying enumerate device interfaces.\n",
dwError);
dwReturn = dwError;
}
if (hDevInfoSet)
SetupDiDestroyDeviceInfoList(hDevInfoSet);
return dwReturn;
}Agora sim... Colocar isso num combo box já é assunto para um outro blog. Até que para um desenvolvedor de drivers, a janela abaixo não está tão ruim assim. Até mais! ;-) Download EnumSerialPort.zip
Lendo Arquivos
Como vocês viram em meu último post, meu trabalho de graduação utilizará uma ferramenta chamada LabView para receber e tratar os dados de uma placa USB. Estes dados serão coletados de um dispositivo chamado giroscópio usando TTL 232, que é um RS 232 com tensões de 0 e 5 volts. Mas como uma prova de conceito, teríamos que fazer o driver simular a recepção de dados para enviar ao LabView. Utilizamos um circuito que transforma TTL 232 em RS 232 apenas para permitir que os dados pudessem ser lidos de uma porta serial convencional. Então fiz um programinha idiota que grava em um arquivo tudo que recebe pela porta serial. Como o firmware ainda não estava nem começado, resolvi fazer um driver que lesse esse arquivo e repassasse os dados para a camada de aplicação. Perguntas sobre como manipular arquivos são especialmente frequentes. Muitos leitores gostariam de saber como criar, ler, escrever e até mesmo apagar arquivos em Kernel Mode. Talvez eu possa desapontá-los um pouco ao dizer que não é assim tão diferente de User Mode, mas já que estamos aqui sem fazer nada, por que não demonstrar? Acredito que a maior diferença esteja no passo onde obtemos o handle para o arquivo. Vamos começar dando uma olhada na rotina ZwCreateFile(). NTSTATUS
ZwCreateFile(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PLARGE_INTEGER AllocationSize OPTIONAL,
IN ULONG FileAttributes,
IN ULONG ShareAccess,
IN ULONG CreateDisposition,
IN ULONG CreateOptions,
IN PVOID EaBuffer OPTIONAL,
IN ULONG EaLength
);A parte interessante desse passo é que a rotina não tem o clássico parâmetro FileName que vimos na API equivalente CreateFile() para User Mode. O nome do arquivo é descrito na estrutura OBJECT_ATTRIBUTES descrita abaixo. typedef struct _OBJECT_ATTRIBUTES {
ULONG Length;
HANDLE RootDirectory;
PUNICODE_STRING ObjectName;
ULONG Attributes;
PVOID SecurityDescriptor;
PVOID SecurityQualityOfService;
} OBJECT_ATTRIBUTES, *POBJECT_ATTRIBUTES;
typedef CONST OBJECT_ATTRIBUTES *PCOBJECT_ATTRIBUTES;Para preencher esta estrutura utilizamos a macro InitializeObjectAttributes(). VOID
InitializeObjectAttributes(
OUT POBJECT_ATTRIBUTES InitializedAttributes,
IN PUNICODE_STRING ObjectName,
IN ULONG Attributes,
IN HANDLE RootDirectory,
IN PSECURITY_DESCRIPTOR SecurityDescriptor
);O caminho do arquivo é descrito no parâmetro ObjectName, que é um ponteiro para uma UNICODE_STRING. Em Kernel, o caminho completo para um arquivo seria descrito como "\Device\HarddiskVolume0\Diretorio\Arquivo.ext" por exemplo. Isso acontece porque a parte "C:", que normalmente utilizamos no caminho de arquivo em User Mode, é um Symbolic Link. Symbolic quem? Um Symbolic Link seria como um atalho para o nome em Kernel Mode. Aplicações em User Mode não podem abrir qualquer objeto do Kernel assim de cara. Então cada driver cria Symbolic Links para os objetos que desejam torná-los disponíveis para User Mode. Quando uma aplicação quer abrir o arquivo "C:\Temp\Test.txt", o sub-sistema Win32 prefixa este caminho com "\??\", que é o diretório inicial desta busca, resultando em "\??\C:\Temp\Test.txt". Quando este nome chega ao Object Manager, o prefixo indica que a busca deve iniciar no diretório "\DosDevices", o mesmo que utilizamos na chamada à API IoCreateSymbolicLink(). Enfim, pulando alguns detalhes para terminar esse post ainda nessa vida, o prefixo vai nos levar ao diretório "\GLOBAL??\". Depois que o prefixo "\??" foi processado, a próxima parte a ser processada é "C:". Utilizando a ferramenta WinObj da Systernals ilustrada na figura abaixo, vemos que aqui em minha máquina "C:" será substituído por "\Device\HarddiskVolume3", que neste caso é o caminho para o device que receberá o restante da string a ser processada. Depois de realizada esta substituição, a string agora é "\Device\HarddiskVolume3\Temp\Test.txt". O Object Manager agora recomeça a processar a string e encontra o device nela descrito.  Depois disso, sabendo que se trata de um device de volume de dados, o sistema consulta uma estrutura chamada Volume Parameter Block (VPB). Ela cria um link que vai nos informar se o volume indicado foi montado por algum driver de File System. No meu caso, o NTFS seria este driver. O device que ele criou faria o restante do tratamento da string para encontrar o arquivo desejado. Você não vai ter que percorrer todo esse caminho para abrir o arquivo. Basta colocar o prefixo "\??\" no caminho do arquivo que desejar abrir e todos os seus problemas se acabaram-se. Se você quiser mais detalhes sobre as traduções de nomes que ocorrem durante a abertura de um arquivo, este artigo da OSR Online é ótimo. Este é o link para a referência que fala sobre isso. Depois de aberto, ler o arquivo fica fácil com a rotina ZwReadFile(). NTSTATUS
ZwReadFile(
IN HANDLE FileHandle,
IN HANDLE Event OPTIONAL,
IN PIO_APC_ROUTINE ApcRoutine OPTIONAL,
IN PVOID ApcContext OPTIONAL,
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset OPTIONAL,
IN PULONG Key OPTIONAL
);Os passos necessários para se abrir e ler um arquivo podem ser resumidos neste pequeno exemplo a seguir.
NTSTATUS ReadTestFile(PVOID pBuffer,
ULONG cbBuffer,
PULONG pulBytesRead)
{
UNICODE_STRING usFileName;
OBJECT_ATTRIBUTES ObjAttributes;
IO_STATUS_BLOCK IoStatusBlock;
HANDLE hFile = NULL;
NTSTATUS nts = STATUS_SUCCESS;
RtlInitUnicodeString(&usFileName,
L"\\??\\C:\\Temp\\Test.txt");
InitializeObjectAttributes(&ObjAttributes,
&usFileName,
OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,
NULL,
NULL);
nts = ZwCreateFile(&hFile,
GENERIC_READ | SYNCHRONIZE,
&ObjAttributes,
&IoStatusBlock,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);
if (!NT_SUCCESS(nts))
return nts;
nts = ZwReadFile(hFile,
NULL,
NULL,
NULL,
&IoStatusBlock,
Buffer,
cbBuffer,
NULL,
NULL);
if (!NT_SUCCESS(nts))
{
ZwClose(hFile);
return nts;
}
*pulBytesRead = IoStatusBlock.Information;
ZwClose(hFile);
return nts;
}
A prova de conceito
Agora que todos nós sabemos como ler um arquivo, fica mais fácil de explicar como fiz um driver que simularia as leituras de um giroscópio apenas lendo o conteúdo de um arquivo. Durante a existência deste blog, já vimos como criar um projetinho do zero, como compilar drivers utilizando o Visual Studio, já vimos também o que é uma IRP, como oferecer serviços de leitura e escrita, como utilizar o FsContext para manter o contexto entre diferentes operações, e como debug é parte do desenvolvimento, também vimos como depurar drivers mesmo em uma máquina virtual. Vamos utilizar toda essa tranqueirada para montar um driver que abra um arquivo, armazene seu handle em uma área de contexto, e que conforme realizamos leituras ao device criado e exportado por ele, este retorne os dados de um arquivo em disco. Isso vai servir direitinho para simular leituras contínuas que o LabView fará ao meu driver USB.
Abrindo o Device e Arquivo
O driver receberá uma chamada de IRP_MJ_CREATE quando um handle para o device for aberto. Vou aproveitar esse evento para já abrir o arquivo e guardar seu handle resultante no FsContext do FILE_OBJECT que receberei. Se você está boiando, dê uma olhada nos posts indicados anteriormente. E se o arquivo não existir? Bom, caso tais eventos infelizes ocorram, vou retornar o erro pela própria IRP recebida. Assim, caso o arquivo não exista ou você não tenha permissão para abri-lo, o código de erro poderá ser verificado através da rotina GetLastError() caso obtivermos INVALID_HANDLE_VALUE como retorno da abertura do handle do device. Dêem uma olhada como ficou a abertura do handle do device, que na mesma operação, abre o handle para o arquivo. Atenção, não misture as coisas. A aplicação vai obter o handle para o device, e através dele, fará leituras ao device. O device por sua vez utilizará o handle do arquivo para fazer leituras e retornar os dados à aplicação.
NTSTATUS OnCreate(PDEVICE_OBJECT pDeviceObj,
PIRP pIrp)
{
UNICODE_STRING usFileName;
OBJECT_ATTRIBUTES ObjAttributes;
IO_STATUS_BLOCK IoStatusBlock;
PIO_STACK_LOCATION pStack;
NTSTATUS nts = STATUS_SUCCESS;
HANDLE hFile = NULL;
RtlInitUnicodeString(&usFileName,
L"\\??\\C:\\Temp\\Test.txt");
InitializeObjectAttributes(&ObjAttributes,
&usFileName,
OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE,
NULL,
NULL);
nts = ZwCreateFile(&hFile,
GENERIC_READ | SYNCHRONIZE,
&ObjAttributes,
&pIrp->IoStatus,
NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,
FILE_OPEN,
FILE_SYNCHRONOUS_IO_NONALERT,
NULL,
0);
pStack = IoGetCurrentIrpStackLocation(pIrp);
pStack->FileObject->FsContext = (PVOID)hFile;
IoCompleteRequest(pIrp,
IO_NO_INCREMENT);
return nts;
}Repare que a API ZwCreateFile() pede um ponteiro para IO_STATUS_BLOCK. Utilizei a mesma estrutura que está contida na IRP que recebemos. Assim eu não tenho que repassar o status de uma operação para a outra. A aplicação continua obtendo o handle para o device da mesma maneira como sempre foi feito, mas lembre-se que se houver uma falha nessa obtenção, o erro pode ter sido gerado por um problema ao abrir o handle do arquivo. Confira como a aplicação vai utilizar o driver.
int __cdecl main(int argc,
char* argv[])
{
char szBuffer[4096];
HANDLE hDevice = NULL;
DWORD dwError = ERROR_SUCCESS,
dwBytes,
i;
printf("Opening the device \"\\\\.\\FileReader\"...\n");
hDevice = CreateFile("\\\\.\\FileReader",
GENERIC_ALL,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hDevice == INVALID_HANDLE_VALUE)
{
dwError = GetLastError();
printf("Error #%d opening device...\n",
dwError);
return dwError;
}
while (ReadFile(hDevice,
szBuffer,
sizeof(szBuffer),
&dwBytes,
NULL))
{
for (i = 0; i < dwBytes; i++)
printf("%c", szBuffer[i]);
}
if ((dwError = GetLastError()) != ERROR_NO_MORE_ITEMS)
printf("\n\n Error #%d reading device...\n");
printf("Closing device...\n");
CloseHandle(hDevice);
return dwError;
}
Lendo o Device e o Arquivo
Faremos a leitura do arquivo de forma similar à abertura. Vamos obter o handle do arquivo a partir do FsContext. Este ponteiro foi originalmente disponibilizado para que o driver pudesse armazenar nele o endereço de uma estrutura definida pelo desenvolvedor. Este ponteiro sempre será o mesmo para todas as operações que utilizam o mesmo FILE_OBJECT até que a operação de IRP_MJ_CLOSE seja chamada. Como um handle é algo muito pequeno, podemos gravar seu valor ao invés de um ponteiro para uma estrutura alocada em memória que contenha o valor do handle. Aqui também vamos utilizar a repassagem da estrutura IO_STATUS_BLOCK para transferir o status da operação de leitura do arquivo para a aplicação.
NTSTATUS OnRead(PDEVICE_OBJECT pDeviceObj,
PIRP pIrp)
{
NTSTATUS nts = STATUS_SUCCESS;
PIO_STACK_LOCATION pStack;
HANDLE hFile;
pStack = IoGetCurrentIrpStackLocation(pIrp);
ASSERT(pStack->FileObject->FsContext != NULL);
hFile = (HANDLE)pStack->FileObject->FsContext;
nts = ZwReadFile(hFile,
NULL,
NULL,
NULL,
&pIrp->IoStatus,
pIrp->AssociatedIrp.SystemBuffer,
pStack->Parameters.Read.Length,
NULL,
NULL);
if (pIrp->IoStatus.Status == STATUS_END_OF_FILE)
nts = pIrp->IoStatus.Status = STATUS_NO_MORE_ENTRIES;
IoCompleteRequest(pIrp,
IO_NO_INCREMENT);
return nts;
}Se nosso driver retornar STATUS_END_OF_FILE para a aplicação, a API ReadFile() não sinalizará uma falha, mas apenas informará que zero bytes foram lidos. Para facilitar a detecção do fim de arquivo lá na aplicação, vou retornar um código de erro diferente, assim a rotina ReadFile() retornará FALSE e o loop de leitura será interrompido.
Fechando o handle do Device e do Arquivo
Agora fica muito fácil. Vamos fechar o handle do arquivo quando o handle do device for fechado. Sem muitas novidades por aqui.
NTSTATUS OnCleanup(PDEVICE_OBJECT pDeviceObj,
PIRP pIrp)
{
PIO_STACK_LOCATION pStack;
HANDLE hFile;
pStack = IoGetCurrentIrpStackLocation(pIrp);
ASSERT(pStack->FileObject->FsContext != NULL);
hFile = (HANDLE)pStack->FileObject->FsContext;
ZwClose(hFile);
pIrp->IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp,
IO_NO_INCREMENT);
return STATUS_SUCCESS;
}Se vocês já são leitores deste blog há algum tempo, verão que o restante do driver contém código elementar e que já foi comentado em outros posts. De qualquer forma, tanto o fonte do driver quando o fonte da aplicação de teste estão disponíveis para download. Caso vocês tenham alguma dúvida é só mandar um e-mail. Normalmente eu digo que vocês só precisarão torcer para eu saber a resposta, mas ultimamente vocês terão que torcer para eu também ter tempo de responder. Como sempre, espero ter ajudado.
Have fun! Download FileReader.zip
110% de CPU
 Eu não queria postar algo que começasse com choradeiras dizendo que estou sem tempo, que tive que buscar minha tia no aeroporto e coisa e tal, mas estou vendo que não vai ter jeito. Até comecei a escrever uns posts para tirar dúvidas de leitores, mas aí eles começam a tomar tempo quando tenho que montar um exemplo, fazer uma figura, etc. Por fim, já tenho dois posts começados, mas que foram abandonados durante sua concepção por falta de tempo. Tenho recebido alguns e-mails do tipo "Você ainda está vivo por aí?" de alguns leitores. As coisas estão realmente complicadas para mim esse ano, mas não vou deixar de postar. Só estou precisando arrumar um tempinho pra sentar. Já tentei escrever posts enquanto almoçava ou tomava banho, mas não deu muito certo. De fato eu consegui escrever um post enquanto dormia, mas quando acordei, por algum motivo, o post não estava publicado. Nota: "Reclamar com o pessoal do blogger". Mas enfm, na falta de tempo suficiente para escrever algo que os ajudem a desenvolver algo, neste post vou apenas relatar o que tenho feito. De repente vocês precisem de algo parecido e queiram me pedir alguma ajuda ou referência. O Último Ano... Parece mentira, mas este é meu último ano da minha graduação em Engenharia da Computação, e por ser o último ano, três agravantes aparecem para disputar meu tempo (como se eu tivesse algum), sendo eles: Dependências, Trabalho de graduação (TG) e o Estágio.  As Dependências... Para quem não lembra ou não sabe o que são dependências, são matérias as quais você não conseguiu ser aprovado no ano em que você estudou, mas consegue passar de ano mesmo assim, só que você terá que estudar estas matérias em separado, seja de sábado ou num horário em que você tenha livre (dá até vontade de rir...). Enfim, cheguei ao sexto ano com três matérias para fazer em meu horário livre. Assim, parte do meu sábado foi e será dedicado a essa atividade. Para fazer uma dependência, é necessário que a universidade agrupe alunos com a mesma matéria para fechar uma turma. Duas das três dependências já formaram turmas, mas ainda preciso rezar para que a terceira turma se forme. Dessa forma eu poderei me matricular. Caso contrário, terei que vir para universidade mais um ano para estudar a matéria restante. Isola...(Toc, toc, toc) vai dar tudo certo.
O Estágio... Em paralelo à essa aventura de estudar três matérias adicionais e ainda ter que passar em tudo, terei que fazer o estágio. Estágio é uma das matérias que preciso fazer para me formar. Terei que cumprir 192 horas de estágio para passar nesta matéria. Felizmente, meu curso pode ter o estágio tanto com ênfase eu software como em hardware, já que a Engenharia da Computação desenvolve as duas especialidades no estudante. Mas Fernando, se me lembro bem, você trabalha na IBM e seu estágio pode sair sem que você tenha que mover um único músculo. Basta alguém assinar seu estágio e pronto.  Pois é, acho que tenho sérias tendências para querer me enrolar. É como meu amigo Heldai me disse uma vez: "Ê seu Fêrnando, o senhor é como eu. Não pode ver uma corda que já quer enrolar no pescoço". O fato é que eu gostaria imensamente de desenvolver meu lado mais fraco, e sabendo que já brinco de fazer telas azuis há um tempo razoável, meu objetivo seria arrumar um estágio em hardware. Mas como isso seria possível se já trabalho numa empresa de software durante a semana? Bom, há um ano atrás, eu dei um curso de desenvolvimento de drivers para Windows em uma empresa que projeta hardware. Uma empresa dessa não se acha assim em qualquer esquina. A Commodity é uma empresa que desenvolve um hardware que faz interface USB, cujo firmware é escrito em linguagem C e roda num chip da Freescale, e como se não fosse o bastante, o hardware ainda faz compressão de audio utilizando um chip da Altera com FPGA. Quem entende de eletrônica sabe que este seria um excelente lugar para fazer estágio e aprender muito. O problema é que eu não poderia fazer o estágio de domingo, que é meu único dia disponível, já que tenho aulas aos sábados e trabalho durante toda a semana. Já que não posso fazer o estágio de domingo, então posso trabalhar de domingo. Mais uma grande vantagem de se fazer Home Office. A solução foi me oferecer para fazer o estágio que seria cumprido apenas de segunda-feira. Estes dias seriam compensados trabalhando de domingo. Pedi autorização para meus gerentes do Brasil e dos Estados Unidos e pronto. Sabendo que um estagiário que aparece uma vez por semana mais atrapalha que ajuda, facilitei minha entrada na empresa solicitando um estágio não remunerado. Como eles já me conheciam, ficou fácil. Apesar de eu não receber nem um centavo e ainda pagar minha gasolina e refeição, tenho certeza de que fiz a escolha certa. Meu estágio começou há duas semanas e tenho tido contato com coisas bem interessantes. Para dar uma acelerada no acúmulo de horas, trabalharei no estágio durantes todos os dias da semana enquanto eu estiver de férias da IBM. Juntando tudo, meu estágio terminará no início de agosto. O TG... Bom, eu já não tinha os sábados e agora não tenho mais os domingos. Só preciso dar um jeito que acabar com qualquer fragmento de tempo livre que eu puder encontrar. Para isso, a universidade nos abençoou com o trabalho de graduação. Nós teremos que montar um projeto que utilize as especialidades que vimos durante o curso de engenharia da computação. Como meta pessoal, não importa o que o projeto faça, terá que haver um driver. Afinal de contas é a única coisa que sei fazer direito. Não posso perder essa oportunidade. Nosso projeto tem como objetivo estabilizar um helimodelo em vôo. Ah tá, e onde o driver entra na história mesmo? Para resumir muito (mas muito mesmo), faremos leituras de um giroscópio embarcado num helimodelo à distância utilizando o protocolo ZigBee. Tais leituras serão realizadas por um kit de desenvolvimento com microcontrolador que fará interface USB com um computador. O driver encaminhará as leituras de movimentos para uma ferramenta chamada LabView. Em resposta à percepção dos movimentos, o sistema reagirá enviando comandos via USB para a placa. A mesma placa fará interface com o rádio controle do helimodelo a fim de corrigir o curso. Em linhas gerais é isso que faremos. Eu poderia escrever muito à respeito de como estamos fazendo isso. Começamos a trabalhar no projeto no ano passado por que já sabíamos que não seria nada fácil. Aproveitei uma das minhas idas para os Estados Unidos para comprar os sensores e kits necessários. O importante é que o projeto está indo bem até aqui, mas ainda vamos apanhar muito. Estou escrevendo o firmware do microcontrolador e obviamente o driver que fará interface com ele, mas nosso principal desafio será fechar a malha de controle e fazer o helimodelo ficar parado no ar.  Parado? Você não tem vergonha de dizer que está fazendo tudo isso para fazer um helimodelo ficar parado? Nosso sonho dourado é definir dois pontos distintos e fazer o trajeto completo com decolagem, delsocamento e pouso, mas quem é helimodelista como eu sabe que fazer um helimodelo ficar parado é um excelente primeiro passo. Nosso orientador já nos disse que nosso projeto é o mais desafiador das engenharias e que se nós fizéssemos apenas a parte da leitura à distância já seria um bom trabalho de graduação. Eu escreveria muito mais sobre o projeto, mas isso vai ficar para depois. Este post já está ficando longo para mais um Off-Topic. Meus agradecimentos à prefeitura municipal de São Paulo por ter criado o rodízio municipal de veículos, e por consequência, ter me trazido para a faculdade com duas horas de antecedência. Isso me deu a oportunidade de começar este post. Agora são 01:45 da manhã e ainda tenho que revisar e publicar esse post. Vou tentar escrever mais. Talvêz minhas aventuras com o TG ou com o estágio me tragam assuntos interessantes e curtos o suficiente para publicar aqui. Até mais mais. :-)
Gerenciando paginação do driver
Depois de tanto falar sobre memória virtual e paginação, recebi uma pergunta que coincidentemente tem tudo a ver com o assunto dos últimos posts. "Para que servem os pragma alloc_text que vemos nos exemplos do WDK?" (Thiago Cardoso, Recife-PE). Essa pergunta já deve ter passado pela cabeça de muitos que já deram uma olhada nos exemplos do WDK. Visto que todos os exemplos do WDK que conheço utilizam este pragma, até que demorou para alguém perguntar sobre isso. Mas enfim, vamos ao que interessa. Como já vimos, páginas de memória podem estar tanto nos chips de RAM como em disco. Também já vimos que threads que estão em alta prioridade de execução não podem acessar dados que são pagináveis. Mas como saberiamos quais dados são pagináveis ou não?
Controlando Paginação de Dados
Quando alocamos memória dinamicamente, podemos escolher se a área de memória a ser alocada será paginável ou não. A função ExAllocatePool, e suas irmãs (ExAllocatePoolWithTag, ExAllocatePoolWithQuota, ExAllocatePoolWithQuotaTag e ExAllocatePoolWithTagPriority), recebem um parâmetro do tipo POOL_TYPE que define se a memória a ser alocada será paginável ou não. typedef enum _POOL_TYPE {
NonPagedPool,
PagedPool,
NonPagedPoolMustSucceed,
DontUseThisType,
NonPagedPoolCacheAligned,
PagedPoolCacheAligned,
NonPagedPoolCacheAlignedMustS
} POOL_TYPE;
PVOID
ExAllocatePool(
IN POOL_TYPE PoolType,
IN SIZE_T NumberOfBytes
);Você terá que gerenciar quais alocações serão acessadas por diferentes prioridades de execução. Por exemplo: Uma determinada lista ligada é consultada apenas por funções que rodam somente em IRQL baixa, logo, todos os seus elementos podem ser alocados em memória paginável (PagedPool). Por outro lado, uma lista ligada que é consultada por funções que rodam em IRQLs altas, deve ter seus elementos alocados em memória não paginável (NonPagedPool). Legal Fernando, mas nem tudo é alocado dinamicamente. Como ficam as variáveis estáticas? Por padrão, todas as variáveis globais são não pagináveis. Isso é ruim se seu driver possui muitas variáveis globais, o que exigiria mais memória não paginável para que seu driver pudesse ser carregado, e como também já foi visto, memória não paginável deve ser poupada. Felizmente, podemos definir que um conjunto de variáveis globais possa ser paginável, desde que estas sejam apenas acessadas por threads em baixa IRQL. Dentro de um módulo, seja uma aplicação, uma DLL ou mesmo um driver, o controle de paginação da memória é aplicado nas sessões que os compõem. Para que um grupo de variáveis seja definido em uma sessão paginável, podemos utilizar o pragma data_seg. Porém, não é todo compilador que nos permite fazer isso. Para saber se o compilador que estamos utilizando suporta o uso deste pragma, contamos com os headers do WDK, que definem o símbolo ALLOC_DATA_PRAGMA quando o compilador oferece suporte a este recurso. Isso, obviamente, tem se tornado menos significante, já que o aconselhável é utilizar o compilador do próprio WDK, mas não custa nada prever que seu código possa ser compilado por algum outro compilador. Veja o exemplo abaixo que define tanto variáveis não pagináveis como pagináveis. PDEVICE_OBJECT g_pControlDeviceObj;
PDRIVER_OBJECT g_pDriverObj;
#ifdef ALLOC_DATA_PRAGMA
#pragma data_seg("PAGEDATA")
#endif
UCHAR g_Buffer[100000];
#ifdef ALLOC_DATA_PRAGMA
#pragma data_seg()
#endif
Controlando Paginação de Código
Memória é memória, seja para armazenar dados ou código. Podemos também controlar onde as funções que você escreve serão definidas. Assim, podemos colocar todas as funções que executam em baixa prioridade em sessões de código pagináveis. Aqui usaremos o pragma que originou a dúvida do Thiago, o pragma alloc_text. Este pragma tem duas limitações. A primeira delas é que o pragma deve ser aplicado depois da declaração da função, mas antes da definição da mesma. A outra é que este pragma não é aplicável em funções C++, ou seja, métodos de classes ou funções com sobrecargas não terão esse luxo de ser pagináveis. Se você é como eu, que prefere utilizar a tipagem forte do C++ em drivers, mesmo que você só escreva simples funções, você deverá utilizar o modificador extern "C" nas declarações das funções. Esse pragma não é obrigatoriamente suportado por todos os compiladores, e assim como o data_seg, os headers do WDK definem o símbolo ALLOC_PRAGMA para sinalizar que o compilador utilizado suporta esse recurso. Segue mais um exemplo. #ifdef __cplusplus
extern "C"
{
#endif
ULONG SumOne(IN ULONG ulParam);
ULONG SumTwo(IN ULONG ulParam);
#ifdef __cplusplus
}
#endif
#ifdef ALLOC_PRAGMA
#pragma alloc_text(PAGE, SumOne);
#pragma alloc_text(PAGE, SumTwo);
#endif
ULONG SumOne(IN ULONG ulParam);
{
PAGED_CODE();
return ulParam + 1;
}
ULONG SumTwo(IN ULONG ulParam);
{
PAGED_CODE();
return SumOne(SomeOne(ulParam));
}Fernando, para quê servem estas macros PAGED_CODE que você usou no exemplo? Bom, lá vem histórinha. Uma coisa desconfortável é que problemas com paginação de memória vão ocorrer apenas quando a página que você está acessando estiver em disco. Isso significa que você pode escrever um driver com problema, testá-lo, e se por "sorte", as páginas estiverem todas em RAM durante o teste, você não verá nenhum problema. Uma das coisas que ajuda bastante é essa macro PAGED_CODE. Em Checked Build, esta macro é traduzida para uma função que irá verificar se a prioridade corrente é baixa suficiente para executar código paginável. Caso não seja, uma exceção de breakpoint será lançada. Espero que você esteja com o depurador atachado para ver isso acontecer. Caso contrário, não se preocupe, uma linda tela azul irá aparecer e você vai acabar conectando o depurador mais cedo ou mais tarde. Quando compilado em Free Build, essa macro é traduzida para nada, evitando perda de performance. Concluindo, isso evita de você chamar uma função paginável em IRQL alta e tudo funcionar por "sorte". ...
#elif DBG
#define PAGED_CODE() { \
if (KeGetCurrentIrql() > APC_LEVEL) { \
KdPrint(("EX: Pageable code called at IRQL %d\n", KeGetCurrentIrql())); \
NT_ASSERT(FALSE); \
} \
}
...
#else
#define PAGED_CODE() NOP_FUNCTION;
...
#endifUma excelente maneira de pegar problemas de paginação de cógido é utilizar o Driver Verifier com a opção de Force IRQL Checking habilitada. Esta opção, além de verificar se você está chamando as funções da API nas prioridades corretas, também força a paginação de tudo que seja paginável em seu driver toda vez que a IRQL subir para DISPATCH_LEVEL ou superior. Isso acaba com aquela "sorte" de utilizar um recurso paginável em IRQL alta quando o recurso já estiver em RAM.
Sessão Descartável
Além da sessão de código paginável PAGE que vimos, uma outra sessão também é vista com grande frequência nos exemplos do WDK. A sessão INIT é descartada quando a chamada à função DriverEntry do seu driver retornar ao sistema, e se for o caso do seu driver, depois que qualquer função de reinicialização for terminada. Se você não sabe o que é uma função de reinicialização, então dê uma passada por este post. Assim, se você tem funções que são somente utilizadas durante a inicialização do seu driver (que neste caso significa: funções chamadas pela DriverEntry, ou funções chamadas por funções que foram chamadas pela DriverEntry, ou ainda funções chamadas por funções que foram chamadas por funções... Ah! Eu acho que você entendeu), vocé pode utilizar o mesmo procedimento para defini-las na sessão INIT da mesma maneira como foi feito anteriormente. Mas não custa deixar um exemplo.
#ifdef ALLOC_PRAGMA
#pragma alloc_text(INIT, DriverEntry);
#pragma alloc_text(INIT, FunctionCalledByDriverEntry);
#pragma alloc_text(INIT, AnotherFunctionCalledByDriverEntry);
#pragma alloc_text(PAGE, SumOne);
#pragma alloc_text(PAGE, SumTwo);
#endifIsso é especialmente útil em Legacy Drivers, que realizam muitos passos na inicialização. Legacy drivers, além de procurar o hardware que vão controlar, ainda precisam fazer a associação dos recursos disponíveis (portas, interrupções, canais de DMA e etc), e isso acaba consumido uma quantidade expressiva de código. Por outro lado, drivers de WDM recebem tudo mastigadinho do Plug-and-Play Manager. O hardware foi detectado e a associação de recursos já foi negociada. Coisa linda de Deus!
Paginável ou não paginável, eis a questão
Supondo que você tenha muitas funções que rodem em IRQL alta, e que por isso, devem estar em memória não paginável, isso faria com que uma grande quantidade de memória não paginável seja utilizada para manter tais funções, mesmo que ninguém esteja utilizando o driver. Também podemos definir nossas próprias sessões e assim torná-las pagináveis ou não pagináveis quando nos for conveniente. Isso permitiria que todas aquelas funções não pagináveis sejam pagináveis enquanto ninguém obtiver uma referência para nosso driver. Desta forma, quando recebermos um IRP_MJ_CREATE ou quando programarmos o hardware para disparar interrupções, podemos dizer ao sistema que agora precisaremos tornar a sessão onde tais funções foram definidas como não paginável. Primeiro de tudo, teremos que criar nossas sessões do coração, e faremos isso utilizando o pragma alloc_text para definir sessões que devem ter seu nome no formato com PAGExxxx, onde xxxx seja um nome único no seu driver. Veja o exemplinho de desencargo de consciência.
#ifdef ALLOC_PRAGMA
#pragma alloc_text(PAGEABCD, FunctionOne);
#pragma alloc_text(PAGEABCD, FunctionTwo);
#endif
#ifdef ALLOC_PRAGMA
#pragma alloc_text(PAGE1234, FunctionThree);
#pragma alloc_text(PAGE1234, FunctionFour);
#endifAgora que já definimos quais funções estarão definidas nessa sessão, podemos torná-la não paginável somente quando tais funções forem utilizadas. Para tal devemos utilizar a função MmLockPagableCodeSection.
PVOID
MmLockPagableCodeSection(
IN PVOID AddressWithinSection
);Para identificar qual sessão será marcada como não paginável, teremos que passar um endereço que esteja dentro da sessão. Um nome de função definida na sessão já resolve o problema, mas lembre-se que todas as funções dentro da mesma sessão serão marcadas como não paginável. A função MmLockPagableCodeSection nos retorna um endereço opaco que pode ser utilizado como parâmetro para a chamada à função MmUnlockPagableImageSection, que marca a sessão novamente como paginável. Essa função é normalmente chamada antes do driver ser descarregado. Seguindo a linha do nosso exemplo, poderiamos chamar esta função ao receber um IRP_MJ_CLOSE. O mesmo endereço retornado por MmLockPagableCodeSection pode ser utilizado como parâmetro às chamadas à função MmLockPagableSectionByHandle para novamente tornar uma sessão não paginável, o que é muito mais rápido que a chamada à MmLockPagableCodeSection. Assim, devemos chamar MmLockPagableCodeSection pelo menos uma vez para obter o ponteiro opaco, e depois disso, podemos chamar MmLockPagableSectionByHandle e MmUnlockPagableImageSection. VOID
MmLockPagableSectionByHandle(
IN PVOID ImageSectionHandle
);
VOID
MmUnlockPagableImageSection(
IN PVOID ImageSectionHandle
);O mesmo pode ser feito em sessões customizadas que definem dados, mas devemos utilizar a função MmLockPagableDataSection para obter o ponteiro opaco que identifica a sessão.
Minha função pode ser paginável?
Fernando, se minha função é chamada em PASSIVE_LEVEL, então ela pode ser paginável? Não é bem assim. Sua função, mesmo sendo chamada em PASSIVE_LEVEL, pode conter intervalos de código que precisam ser não pagináveis. Se você chamar funções que elevam a IRQL, tais como KeAcquireSpinLock, sua função não pode ser definida em sessão paginável. Mas Fernando, acompanhe o meu raciocínio. Se a função foi chamada e está em execução no momento, não é obvio que a página à qual ela está contida está em RAM? Você pode até não acreditar, mas uma função é composta por uma cadeia de bytes que podem estar nas fronteiras de páginas. Isso significa que o inicio da sua função pode estar no final de uma página, que de fato foi paginada para RAM quando a chamada foi feita, mas não sabemos onde uma nova página pode começar. Esta nova página pode estar em disco, e se for acessada em IRQL alta, a paginação causará uma tela azul. Veja o código abaixo para ter uma idéia do que estou falando e não esqueça de ler os comentários.
PLIST_ENTRY
FunctionCalledAtPassiveLevel(VOID)
{
KIRQL Irql;
PLIST_ENTRY pEntry = NULL;
PAGED_CODE();
KeAquireSpinLock(&g_SpinLock, &Irql);
if (!IsListEmpty(&g_NonPagedList))
{
pEntry = RemoveHeadList(&g_NonPagedList);
}
KeReleaseSpinLock(Irql);
return pEntry;
}Se você possui funções que são grandes, mas que contém intervalos pontuais com elevação de IRQL, então separe tais intervalos em funções isoladas que podem ser definidas em sessões não pagináveis, permitindo assim que você defina sua grande e complexa funcão em uma sessão paginável. Ufa! Eu ainda poderia escrever mais alguns comentários sobre este assunto, mas se eu já estou cansado de escrever, imagino como vocês estão. O assunto é tratado com todos detalhes na referência. Mas se tiverem qualquer dúvida a respeito, é só me enviar um e-mail e torcer pra eu saber responder. Até mais!
Buffered, Direct ou Neither em IOCTLs
Depois de uma pitada de memória virtual para entendermos os conceitos mais relevantes e darmos uma boa passeada nos métodos de transferências de dados entre aplicação e driver, hoje vamos fechar essa trilogia falando sobre os métodos de transferências de dados em IOCTLs. Se você não sabe criar ou utilizar IOCTLs, este outro post pode ajudar.
Flags não ajudam aqui
No post referente aos métodos de transferências de dados foi visto que definimos o método de transferência através de uma máscara de bits que está localizada no campo Flags em um DEVICE_OBJECT. O método escolhido aqui define como o I/O Manager vai manipular os dados nas operações de leitura (IRP_MJ_READ) e escrita (IRP_MJ_WRITE) do driver. O método escolhido é aplicado para ambas as operações. Não podemos ter escritas utilizando um método enquanto as leituras são realizadas utilizando outro. No caso das IOCTLs, a história é diferente. O método de transferência é escolhido quando se define o control code utilizando a macro CTL_CODE.
#define IOCTL_Device_Function CTL_CODE(DeviceType, Function, Method, Access) Para se ter uma explicação mais detalhada sobre o uso desta macro, visite este post, ou dê uma olhada na referência. Aqui comentarei apenas sobre os métodos de transfêrencias de dados que é selecionado pelo parâmetro Method desta macro. A utilização desta macro para definir IOCTLs é normalmente feita em um arquivo de header que será compartilhado entre a aplicação e o driver. A definição desta macro é obtida a partir do header Windows.h para User-Mode e Ntddk.h para Kernel-Mode. Abaixo segue a definição dos IOCTLs que implementaremos neste post.
#define IOCTL_COPY_BUFFERED CTL_CODE(FILE_DEVICE_UNKNOWN, \
0x800, \
METHOD_BUFFERED, \
FILE_ANY_ACCESS)
#define IOCTL_COPY_DIRECT CTL_CODE(FILE_DEVICE_UNKNOWN, \
0x801, \
METHOD_OUT_DIRECT, \
FILE_ANY_ACCESS)
#define IOCTL_COPY_NEITHER CTL_CODE(FILE_DEVICE_UNKNOWN, \
0x802, \
METHOD_NEITHER, \
FILE_ANY_ACCESS)Como se pode observar, podemos ter diferentes métodos de transferência de dados para diferentes IOCTLs. Neste post vou criar um driver que ofereça três IOCTLs que simplesmente copiam os dados recebidos no buffer de entrada para buffer de saída. O que teremos que fazer inicialmente é utilizar a macro CTL_CODE para criar as IOCTLs dos serviços que nosso driver de exemplo irá oferecer. O código completo do driver de exemplo está disponível para download ao final deste post. Pô Fernando, eu incluí o Windows.h em minha aplicação de teste, mas ainda está faltando a definição da macro CTL_CODE e recebo a mensagem de erro abaixo. Estou usando um Windows.h incompleto? Z:\sources\testapp.cpp(45) : error C3861: 'CTL_CODE': identifier not found O negócio é o seguinte: O Wizard das versões mais recentes do Visual Studio cria o arquivo StdAfx.h contendo, entre outras, as seguintes linhas: #define WIN32_LEAN_AND_MEAN #include <windows.h>  Observe que o símbolo WIN32_LEAN_AND_MEAN é definido antes da inclusão do arquivo Windows.h. A fim de ganhar velocidade de compilação, este símbolo evita a declaração de algumas toneladas de definições que raramente são utilizadas por aplicações. O que está acontecendo é que a macro CTL_CODE é uma destas coisas raramente utilizadas. É rapaz, interagir com drivers não é pra qualquer um não. Enfim, para resolver este problema é só comentar a definição deste símbolo e todos viverão felizes para sempre. Calma lá Fernando! Todos menos eu, que não usei o Wizard do Visual Studio. Estou utilizando o arquivo SOURCES para compilar minha aplicação. O fato é que em meu fonte não existe nenhuma definição desse tal de "Win32 Lemming". Qual é a desculpinha agora? Se você está utilizando o arquivo SOURCES para compilar sua aplicação de teste, assim como estou fazendo no exemplo deste post, você precisará adicionar a linha em destaque abaixo para que o símbolo WIN32_LEAN_AND_MEAN não seja definido pelo makefile padrão do WDK. TARGETNAME=TestApp
TARGETTYPE=PROGRAM
USE_LIBCMT=1
UMTYPE=console
NOT_LEAN_AND_MEAN=1
SOURCES=TestApp.cpp
Utilizando um buffer de sistema
O primeiro método que veremos aqui é o Buffered I/O, definido pela utilização do valor METHOD_BUFFERED como parâmetro da macro CTL_CODE. Aqui não teremos grandes novidades para quem leu o post anterior. A grande diferença aqui é que na mesma chamada ao driver, dois bufferes são passados para a função DeviceIoControl, um de entrada e outro de saída. Aqui o I/O Manager vai alocar um único buffer de sistema com o tamanho igual ao maior deles. Complicou? Um exemplo ajuda. Numa chamada em que a aplicação ofereça o buffer de entrada com 50 bytes e um buffer de saída com 100 bytes, o buffer de sistema será alocado com 100 bytes. O I/O Manager vai copiar os 50 bytes do buffer de entrada da aplicação para o buffer de sistema. A IRP é enviada ao driver, e ao ser completada, o I/O Manager copia o conteúdo do buffer de sistema para o buffer de saída da aplicação. Quantidade de bytes copiada de volta à aplicação é determinada pelo campo pIrp->IoStatus.Information, assim como no post anterior. Uma coisa importante a ser notada aqui é que já que o buffer de sistema é único tanto para a entrada como para saída dos dados, o driver precisa ler os dados de entrada antes de começar a escrever os dados de saída, que sobrescreveriam o buffer de entrada. Conforme já comentei, nosso driver de exemplo vai copiar o buffer de entrada para o buffer de saída. Vamos dar uma olhada na implementação da nossa rotina que vai tratar o IOCTL que usará um buffer de sistema. Leiam os comentários.
NTSTATUS
OnCopyBuffered(IN PDEVICE_OBJECT pDeviceObj,
IN PIRP pIrp)
{
NTSTATUS nts;
PIO_STACK_LOCATION pStack;
pStack = IoGetCurrentIrpStackLocation(pIrp);
DbgPrint("========== OnCopyBuffered ===========\n"
"Input buffer address: 0x%p\n"
"Input buffer size: %d\n"
"Output buffer addres: 0x%p\n"
"Output buffer size: %d\n\n",
pIrp->AssociatedIrp.SystemBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength,
pIrp->AssociatedIrp.SystemBuffer,
pStack->Parameters.DeviceIoControl.OutputBufferLength);
if (pStack->Parameters.DeviceIoControl.OutputBufferLength <
pStack->Parameters.DeviceIoControl.InputBufferLength)
{
nts = STATUS_BUFFER_TOO_SMALL;
pIrp->IoStatus.Information = 0;
}
else
{
nts = STATUS_SUCCESS;
pIrp->IoStatus.Information =
pStack->Parameters.DeviceIoControl.InputBufferLength;
}
pIrp->IoStatus.Status = nts;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
Travando a memória da Aplicação
Apesar de o IOCTL ser uma solicitação normalmente utilizada para controle, nada nos impede de utilizar este meio de comunicação para obter ou enviar dados para o driver. Se nestas leituras ou escritas, grandes volumes de dados forem trocados, o método Buffered passa a ser pouco eficiente. Utilizando o método Direct não haverá cópias intermediárias em buffer de sistema. Nada muito diferente do que já vimos no post anterior, mas aqui temos dois bufferes em uma só chamada. O buffer de entrada faltou na escola bem no dia da aula sobre MDLs, e por isso ainda chega ao driver utilizando um buffer de sistema. É isso mesmo! Igualzinho ao método buffered. Por esta razão, não usaremos o buffer de entrada para enviar grandes quantidades de dados ao driver. Mas e se eu quiser enviar uma grande quantidade de dados para o driver através de um IOCTL? Aqui a conversa entorta um pouco. Repare que para utilizar o método Direct em IOCTLs, podemos usar tanto o parâmetro METHOD_IN_DIRECT como o METHOD_OUT_DIRECT. Com o método Direct, você pode utilizar o buffer de saída como entrada para o driver. Hein? Tá bom, vamos mais devagar. Ambas as opções criam uma MDL para descrever as páginas que compõem o buffer de saída oferecido pela aplicação. Quando a IRP chega ao driver, você utiliza a função MmGetSystemAddressForMdlSafe para obter um ponteiro de System Space que mapeia as mesmas páginas físicas oferecidas pela aplicação. Isso significa que o ponteiro que você recebe vai escrever diretamente nas páginas oferecidas pela aplicação. Já sei! Se o ponteiro aponta para as mesmas páginas da aplicação, então podemos ler os dados contidos nestas páginas? É exatamente isso. Podemos enviar dados ao driver preenchendo o buffer de saída antes de chamar a função DeviceIoControl. Assim, quando o driver receber a IRP, ele pode ler estes dados. Isso permite que o driver receba grandes quantidades de dados de entrada, mas utilizando o buffer de saída. O parâmetro METHOD_IN_DIRECT sinaliza ao I/O Manager que o buffer que será utilizado para montar a MDL será utilizado para leitura, assim o buffer é testado para leituras no processo de criação da MDL. Alternativamente, o parâmetro METHOD_OUT_DIRECT indica que o buffer receberá leituras e escritas do driver. Lembre-se que METHOD_IN_DIRECT ou METHOD_OUT_DIRECT define apenas o tipo de teste que será feito sobre o buffer de saída, permitindo do driver ler o buffer de saída. O buffer de entrada sempre virá por intermédio de um buffer de sistema. Tá tá tá, vamos ao código por favor?
NTSTATUS
OnCopyDirect(IN PDEVICE_OBJECT pDeviceObj,
IN PIRP pIrp)
{
NTSTATUS nts;
PIO_STACK_LOCATION pStack;
PVOID pOutputBuffer;
pStack = IoGetCurrentIrpStackLocation(pIrp);
pOutputBuffer = MmGetSystemAddressForMdlSafe(pIrp->MdlAddress,
LowPagePriority);
if (!pOutputBuffer)
{
pIrp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_INSUFFICIENT_RESOURCES;
}
DbgPrint("=========== OnCopyDirect ============\n"
"Input buffer address: 0x%p\n"
"Input buffer size: %d\n"
"Output buffer addres: 0x%p\n"
"Output buffer size: %d\n\n",
pIrp->AssociatedIrp.SystemBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength,
pOutputBuffer,
pStack->Parameters.DeviceIoControl.OutputBufferLength);
if (pStack->Parameters.DeviceIoControl.OutputBufferLength <
pStack->Parameters.DeviceIoControl.InputBufferLength)
{
nts = STATUS_BUFFER_TOO_SMALL;
pIrp->IoStatus.Information = 0;
}
else
{
RtlCopyMemory(pOutputBuffer,
pIrp->AssociatedIrp.SystemBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength);
nts = STATUS_SUCCESS;
pIrp->IoStatus.Information =
pStack->Parameters.DeviceIoControl.InputBufferLength;
}
pIrp->IoStatus.Status = nts;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
Nem Buffered I/O nem Direct I/O
Isso pode parecer repetitivo para você, mas neste método, indicado pelo parâmetro METHOD_NEITHER, o I/O Manager não fará nada por você. Assim, você terá que testar o contexto do processo e também testar o acesso aos bufferes como vimos no post anterior. Mais uma vez, a grande diferença aqui é que teremos dois bufferes. O buffer de entrada virá por pStack->Parameters.DeviceIoControl.Type3InputBuffer e o buffer de saída é obtido por pIrp->UserBuffer. O buffer de entrada deve ser testado com ProbeForRead, já que o driver fará leituras neste buffer, e o buffer de saída deve ser testado com ProbeForWrite. Acho que o resto o código de exemplo é capaz de explicar. Para testar o contexto do processo, utilizamos a função que já foi explicada no post anterior.
NTSTATUS
OnCopyNeither(IN PDEVICE_OBJECT pDeviceObj,
IN PIRP pIrp)
{
NTSTATUS nts;
PIO_STACK_LOCATION pStack;
pStack = IoGetCurrentIrpStackLocation(pIrp);
DbgPrint("=========== OnCopyNeither ===========\n"
"Input buffer address: 0x%p\n"
"Input buffer size: %d\n"
"Output buffer addres: 0x%p\n"
"Output buffer size: %d\n\n",
pStack->Parameters.DeviceIoControl.Type3InputBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength,
pIrp->UserBuffer,
pStack->Parameters.DeviceIoControl.OutputBufferLength);
if (!EstouNoContextoDoProcessoQueGerouEssaIrp(pIrp))
{
pIrp->IoStatus.Status = STATUS_INVALID_ADDRESS;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_INVALID_ADDRESS;
}
__try
{
ProbeForRead(pStack->Parameters.DeviceIoControl.Type3InputBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength,
1);
ProbeForWrite(pIrp->UserBuffer,
pStack->Parameters.DeviceIoControl.OutputBufferLength,
1);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
nts = GetExceptionCode();
pIrp->IoStatus.Status = nts;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
if (pStack->Parameters.DeviceIoControl.OutputBufferLength <
pStack->Parameters.DeviceIoControl.InputBufferLength)
{
nts = STATUS_BUFFER_TOO_SMALL;
pIrp->IoStatus.Information = 0;
}
else
{
RtlCopyMemory(pIrp->UserBuffer,
pStack->Parameters.DeviceIoControl.Type3InputBuffer,
pStack->Parameters.DeviceIoControl.InputBufferLength);
nts = STATUS_SUCCESS;
pIrp->IoStatus.Information =
pStack->Parameters.DeviceIoControl.InputBufferLength;
}
pIrp->IoStatus.Status = nts;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
Compilando o exemplo
Para compilar o exemplo disponível para download, você pode utilizar o atalho de ambiente instalado pelo WDK e chamar o Build do diretório raiz do exemplo. Repare que em um único passo compilamos o driver e a aplicação de teste. A figura abaixo ilustra isso. Ou você pode usar o DDKBUILD como eu já expliquei neste outro post para compilar a partir do Visual Studio. Fernando, mais uma dúvida antes de você sumir na névoa. Na tabela de Dispatch Routines, que preenchemos na estrutura DRIVER_OBJECT, contém apenas uma entrada para IRP_MJ_DEVICE_CONTROL. Como você criou uma rotina para cada método? Essa eu vou deixar o código de exemplo abaixo responder, mas se ainda assim você tiver alguma dúvida, é só me mandar um e-mail, que está em meu perfil do Blogger, e aí a gente sai na porrada.
NTSTATUS
OnDeviceControl(IN PDEVICE_OBJECT pDeviceObj,
IN PIRP pIrp)
{
PIO_STACK_LOCATION pStack;
pStack = IoGetCurrentIrpStackLocation(pIrp);
switch(pStack->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_COPY_BUFFERED:
return OnCopyBuffered(pDeviceObj,
pIrp);
case IOCTL_COPY_DIRECT:
return OnCopyDirect(pDeviceObj,
pIrp);
case IOCTL_COPY_NEITHER:
return OnCopyNeither(pDeviceObj,
pIrp);
}
pIrp->IoStatus.Status = STATUS_NOT_IMPLEMENTED;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_NOT_IMPLEMENTED;
}Hoje vou me despedir ao estilo mr4nd3r50n, que é um amigo que trabalhou comigo na SCUA. Intel mais, já vou Windows!
:-) Download IoctlCopy.zip
Buffered, Direct ou Neither
No post passado apresentei uma breve introdução sobre alguns pontos referentes à memória virtual que considero ser os mais relevantes aos desenvolvedores de drivers. Com essa pequena carga de conhecimento, ficará mais simples de explicar as diferenças entre os métodos de transferências de dados entre aplicações e drivers, assim como outras questões, tais como o atendimento de interrupções, mapeamento de memória e contexto de execução. Se formos pensar de maneira bem simplificada (e bota simplificada nisso), drivers são basicamente os módulos que extraem dados de dispositivos e os disponibilizam para as aplicações e vice-versa. Deste ponto de vista, parece mesmo que escrever drivers seja fácil. Parece até uma maneira de fazer um memcpy de software para hardware. Hoje veremos um pouco sobre as maneiras as quais um driver pode optar para fazer essa transferência de dados.
Utilizando um Buffer de sistema
O primeiro método é o chamado Buffered I/O. Este método utiliza um buffer de sistema para fazer a transferência de dados entre a aplicação e o driver. Quando uma aplicação chama a função WriteFile passando os dados a serem enviados para o driver, o I/O Manager faz uma cópia dos dados da aplicação para um buffer de sistema. Mas o que é um buffer de sistema? Se trata de uma alocação em System Space que foi feita em Kernel-Mode, e por isso, é acessível em qualquer contexto de processo. Já falamos disso no post passado. BOOL WINAPI WriteFile(
__in HANDLE hFile,
__in LPCVOID lpBuffer,
__in DWORD nNumberOfBytesToWrite,
__out_opt LPDWORD lpNumberOfBytesWritten,
__inout_opt LPOVERLAPPED lpOverlapped
); O I/O Manager obtém o tamanho do buffer a ser alocado do parâmetro nNumberOfBytesToWrite, então realiza uma alocação de memória do tipo não paginada e faz a cópia dos dados que estão em User Space para System Space. Se você estiver derrapando nos termos System Space, User Space e tipos de alocação de memória, dê uma lida neste post para que as coisas fiquem menos obscuras para você. No driver, o ponteiro para este buffer é obtido pela IRP e seu tamanho é obtido pela stack location da IRP. Legal, mas o que é uma IRP? Dê uma olhada neste mini exemplo abaixo para ter uma idéia, ou você pode ver o exemplo utilizado neste outro post que também utiliza o método Buffered para enviar e receber strings de um driver de exemplo.
NTSTATUS
OnDispatchWrite(__in PDEVICE_OBJECT pDeviceObj,
__in PIRP pIrp)
{
PIO_STACK_LOCATION pStack;
PVOID pBuffer;
ULONG ulLength;
pStack = IoGetCurrentIrpStackLocation();
pBuffer = pIrp->AssociatedIrp.SystemBuffer;
ulLength = pStack->Parameters.Write.Length;
...
}Nas operações de leitura, o método é bem parecido, mas apesar de neste caso o I/O Manager também fazer a locação em memória não paginada, ele não faz nenhuma cópia para o buffer de sistema. O buffer de sistema é recebido pelo driver também através de pIrp->AssociatedIrp.SystemBuffer, mas o seu tamanho é obtido em pStack->Parameters.Read.Length. O driver preencherá o buffer com os dados vindos do dispositivo, o I/O Manager fará a cópia do buffer de System Space para User Space quando a IRP for completada, preenchendo o buffer da aplicação. Opa opa! Até onde eu sei, drivers normalmente completam IRPs em contexto arbitrário, o que significa que "só Deus sabe em qual contexto de processo". Tudo bem se o driver escrever em um buffer de sistema, o qual é válido para qualquer processo, mas o buffer da aplicação está em User Space e só é acessível no contexto do próprio processo. Como o I/O Manager faria a cópia do buffer de sistema para o buffer da aplicação em contexto arbitrário? Nossa, essa realmente foi uma excelente pergunta. Acho que nem eu teria imaginado uma pergunta tão boa. As IRPs podem ser tratadas tanto sincronamente como assincronamente. O I/O Manager sabe como a IRP foi processada, e no caso síncrono, o I/O Manager já está no contexto do processo que fez a solicitação, e neste caso ele tem acesso a ambos os bufferes, já que o I/O Manager roda em Kernel-Mode. Quando a IRP é tratada assincronamente, o I/O Manager enfila uma APC (Asynchronous Procedure Call), que é uma chamada assincrona executada no contexto de uma dada thread. Essa thread é justamente a thread que iniciou a operação, e que portanto, estará no contexto do processo certo para acessar o User Space da aplicação. BOOL WINAPI ReadFile(
__in HANDLE hFile,
__out LPVOID lpBuffer,
__in DWORD nNumberOfBytesToRead,
__out_opt LPDWORD lpNumberOfBytesRead,
__inout_opt LPOVERLAPPED lpOverlapped
); Na chamada da função ReadFile, o parâmetro nNumberOfBytesToRead indica o tamanho do buffer que a aplicação está oferecendo ao driver. O driver recebe este valor como quantidade máxima de bytes que podem ser retornados à aplicação. Supondo que a aplicação tenha oferecido 1000 bytes, o I/O Manager faz uma alocação de 1000 bytes e repassa o buffer para o driver. Vamos supor que o driver tenha apenas 500 bytes a serem retornados à aplicação, neste caso, o I/O Manager terá de copiar para o buffer da aplicação apenas 500 dos 1000 bytes alocados. O I/O Manager recebe este valor através do campo pIrp->IoStatus.Information, que é preenchido pelo driver antes da IRP ser completada. Desta forma, o I/O Manager copia somente os bytes válidos do buffer de sistema para o buffer da aplicação. Este mesmo valor é retornado à aplicação através do parâmetro lpNumberOfBytesRead. Utilizar memória não paginada para o manter o buffer de sistema nos assegura que as páginas não serão removidas da RAM por paginação. Isso permite que a página seja acessada mesmo a partir de threads que estejam rodando em alto nível de prioridade. Contudo, o método Buffered é indicado apenas para pequenas movimentações de dados. Imagine que uma aplicação queira fazer uma escrita de 10 MB de uma só vez. O I/O Manager teria que fazer uma alocação em System Space de 10 MB de memória não paginada, o que não seria nada adequado, pois memória não paginada é um recurso escasso. Se o I/O Manager conseguir fazer a alocação, ele ainda terá que fazer uma cópia de 10 MB do buffer da aplicação para o buffer de sistema. Isso até funcionaria, mas teriamos sérios problemas de performace. Neste caso, o mais indicado seria utilizar o método que é visto em seguida.
Travando a memória da Aplicação
No método chamado Direct I/O, como o nome já sugere, o driver faz acesso diretamente às páginas de memória da aplicação sem utilizar um buffer intermedirário. Desta forma, o I/O Manager não faz uma alocação em memória não paginada e também não tem que ficar no BPL-BPC (Buffer pra lá - Buffer pra cá). Ao invés disso, o I/O Manager testa as páginas de memória que compõem o buffer oferecido pela aplicação, cria uma MDL e trava as páginas de memória na RAM. Nossa! Calma aí meu amigo, vamos devagar! - Testa as páginas de memória - Nada impede um programador de fazer besteira. Um buffer inválido pode ser passado para o I/O Manager. Pode ser que o buffer não tenha sido alocado, ou que o buffer seja menor que o valor indicado na chamada às funções ReadFile ou WriteFile, pode ser também que as páginas de memória oferecidas à ReadFile estejam protegidas contra escrita, pode ser também que algumas das páginas utilizadas pelo buffer tenham sido paginadas para o disco. Se um driver tenta acessar uma página inválida ou protegida, uma exceção é gerada e uma tela azul sugirá das trevas. Mas como o I/O Manager vai testar a memória? Se o buffer é passado como parâmetro para a função ReadFile, então o driver fará escritas neste buffer. Para ganhar tempo, o I/O Manager fará uma escrita de um byte de cada página de RAM apenas para testar o acesso a elas. Essa escrita é feita sob um manipulador de exceção. Se o buffer for inválido ou protegido, o manipulador de exceção tratará isso e devolverá um erro para a aplicação. Se o buffer é passado para a função WriteFile, então o buffer será lido pelo driver, e neste caso, o teste seria a leitura de um byte de cada página.
- Cria uma MDL - Uma MDL (Memory Descriptor List) é uma estrutura de dados que descreve as várias páginas de memória que compõem um buffer. Estas páginas são as mesmas páginas físicas utilizadas pela aplicação, ou seja, quando o driver escrever nestas páginas, este já estará escrevendo diretamente no buffer da aplicação. Assim o I/O Manager não precisará fazer nenhum BPL-BPC.
- Trava as páginas na RAM - Esse passo faz com que as páginas de memória que compõem o buffer da aplicação se tornem não pagináveis. Assim, estas poderão ser acessadas pelo driver em threads que estejam sendo executadas em alto nível de prioridade.
Depois de todo esse ritual, o driver agora recebe o buffer através de pIrp->MdlAddress, mas o que teremos aqui é um ponteiro para uma MDL. Mas o que eu faço com uma MDL? Na maioria das vezes, você vai passar como argumento em um serviço oferecido por outro driver ou componente do sistema. Alguns exemplos são drivers de DMA (Direct Memory Access) que utilizam MDL na chamada para a função MapTransfer, ou mesmo quando uma MDL é repassada para rotinas de controladores USB (Universal Serial Bus), tais como UsbBuildInterruptOrBulkTransferRequest. MDLs são estruturas opacas, mas se você quer ter acesso ao buffer da aplicação, então devemos chamar a função MmGetSystemAddressForMdlSafe para conseguir o endereço para o buffer a ser escrito/lido. Reparem que o endereço retornado por esta função está em System Space, e assim, acessível em qualquer contexto de processo. Mas o buffer da aplicação não está em User Space? Sim, mas o que temos aqui é uma página de memória física sendo mapeada tanto para o espaço de endereçamento da aplicação quanto para o espaço de endereçamemto de sistema. O tamanho do buffer descrito pela MDL também é obtido pela stack location da IRP, assim como no método Buffered.
Nem Buffered I/O nem Direct I/O
O terceiro método é simplesmente o não uso dos dois primeiros. No método chamado Neither, o I/O Manager não faz uma cópia em um buffer de sistema nem monta uma MDL para descrever o buffer da aplicação. Quando a IRP chega ao seu driver, você tem acesso ao endereço virtual do buffer oferecido pela aplicação por pIrp->UserBuffer. Este endereço aponta para User Space, e por isso, lembre-se que este endereço só é valido no contexto do processo que solicitou o I/O. O uso deste método requer mais cuidado, pois seu driver precisa ser o primeiro driver na pilha de dispositivos, e dessa forma, garantir que a IRP chegue ao seu driver no contexto do prcesso que fez a solicitação de I/O. Você pode verificar se você está no contexto do processo que solicitou a operação fazendo o teste abaixo.
BOOLEAN EstouNoContextoDoProcessoQueGerouEssaIrp(__in PIRP pIrp)
{
PETHREAD pEThread;
PEPROCESS pEProcess;
pEThread = pIrp->Tail.Overlay.Thread;
pEProcess = IoThreadToProcess(pEThread);
return (PsGetCurrentProcess() == pEProcess);
}O fato de estar no contexto do processo correto não garante que o buffer passado como parâmetro seja válido. Diferente do método Direct, neste ponto o I/O Manager não testou o buffer antes de passar a IRP para o driver. Teremos que fazer isso por nós mesmos. Lembre-se que, assim como em User-Mode, ao acessar um buffer inválido o driver receberá uma exceção que deve ser manipulada, caso contrário, tudo azul. Para realizar o teste, teremos que acessar um byte de cada página do buffer que nos foi passado e verificar se o mundo acaba. As rotinas ProbeForRead e ProbeForWrite fazem isso por nós, mas estas devem ser chamadas dentro de um manipulador de exceção. Vale lembrar que em uma operação de leitura, a aplicação nos envia um buffer onde o driver escreverá dados para a aplicação. Já que o driver fará uma escrita neste buffer, teremos que realizar um teste de escrita (ProbeForWrite) nas operações de leitura (ReadFile). De maneira análoga, o driver deverá fazer um teste de leitura (ProbeForRead) nas operações de escrita (WriteFile). Dê uma olhada no exemplo de rotina de leitura que segue abaixo. Como você já deve estar acostumado, leia os comentários que complementam o texto.
NTSTATUS OnDispatchRead(__in PDEVICE_OBJECT pDeviceObj,
__in PIRP pIrp)
{
PIO_STACK_LOCATION pStack;
PVOID pBuffer;
ULONG ulLength;
if (!EstouNoContextoDoProcessoQueGerouEssaIrp(pIrp))
{
pIrp->IoStatus.Status = STATUS_INVALID_PARAMETER;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_INVALID_PARAMETER;
}
pStack = IoGetCurrentIrpStackLocation(pIrp);
pBuffer = pIrp->UserBuffer;
ulLength = pStack->Parameters.Read.Length;
__try
{
ProbeForWrite(pBuffer,
ulLength,
1);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
NTSTATUS nts;
nts = GetExceptionCode();
pIrp->IoStatus.Status = nts;
pIrp->IoStatus.Information = 0;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return nts;
}
for (ULONG i = 0; i < ulLength, i++)
((PUCHAR)pBuffer)[i] = (UCHAR)i;
pIrp->IoStatus.Status = STATUS_SUCCESS;
pIrp->IoStatus.Information = ulLength;
IoCompleteRequest(pIrp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}Para todos os métodos, é importante notar que setar o campo pIrp->IoStatus.Information diz à aplicação a quantidade de bytes foram lidos ou escritos no buffer, independente de haver ou não a cópia de buffer de sistema como no caso do método Buffered. Outra coisa que não vai mudar para os diferentes métodos é a obtenção do tamanho do buffer oferecido pela aplicação. Este valor sempre vem pela stack location como já foi visto nos métodos já discutidos.
Como selecionar o método
Faz todo o sentido que a escolha do método seja feita antes da primeira IRP chegar ao driver. Isso é feito logo depois que o device é criado. Depois que a chamada à função IoCreateDevice termina, recebemos o novo device através de um ponteiro de saída. O membro Flags da estrutura DEVICE_OBJECT é uma máscara de bits e os bits DO_BUFFERED_IO e DO_DIRECT_IO configuram o método de transferência. Então é fácil assim. Para configurar o método Buffered, setamos o bit DO_BUFFERED_IO, para configurar o método Direct, setamos o bit DO_DIRECT_IO, e finalmente para setar o método Neither, não setamos nenhum destes bits. Já li em algum livro, que não encontro agora, que o comportamento não é previsto se você setar ambos os bits. Segue mais um exemplinho besta de como setar o device que acaba de ser criado para transferências no método Buffered. nts = IoCreateDevice(pDriverObj,
0,
&usDeviceName,
FILE_DEVICE_UNKNOWN,
0,
FALSE,
&pDeviceObj);
if (!NT_SUCCESS(nts))
return nts;
pDeviceObj->Flags |= DO_BUFFERED_IO;Mas e se uma IRP for entregue ao driver antes de setarmos estes bits? Outra excelente pergunta. As coisas acontecem assim. Sempre quando um novo device é criado, o bit DO_DEVICE_INITIALIZING é setado. As IRPs só começam a ser entregues a este device quando o driver baixar este bit. Isso nos permite inicializar o device antes que qualquer IRP chegue. Boa tentativa espertão, mas seu exemplo não baixa este bit. Como você explica isso? Você hoje está impossível! Ao termino da rotina DriverEntry, quando o controle volta ao I/O Manager, ele varre a lista de devices criados pelo driver e baixa este bit por nós. É importante lembrar que ainda precisamos baixar este bit quando criamos um novo device depois que a rotina DriverEntry terminou. Um exemplo muito comum são os devices de WDM, que são criados na rotina AddDevice, mas isso vai ficar para uma outra vez. Esse post já ficou muito longo. Até mais! :-)
|
|
