Mapeando Arquivos em Memória
Depois de ilustrar algumas das características do Memory Manager sendo um provedor de serviços ao Cache Manager no post anterior, hoje vou demonstrar que meras aplicações User-Mode também podem utilizar tais serviços. Mapeando arquivos em memória a aplicação ganha um intervalo de endereços virtuais que contém o conteúdo do arquivo. O acesso ao conteúdo do arquivo se dá simplesmente desreferenciando um ponteiro, sem a necessidade de chamar as funções ReadFile() ou WriteFile().
Quer uma necessidade para isso? Imagine que sua aplicação precise fazer a busca por uma determinada string em um arquivo, digamos “DriverEntry”. Em um desevolvimento “arroz com feijão”, o handle do arquivo é obtido através da chamada à função CreateFile(), e um buffer recebe o conteúdo parcial do arquivo, vamos supor 200 bytes. Uma simples função de busca da API poderia fazer tal busca no buffer.
Essa solução seria perfeita se não houvesse a possibilidade de a palavra buscada cair nas extremidades do buffer tal como ilustrado abaixo.
Um algoritmo mais espertinho teria que ser utilizado para identificar o prefixo e continuar a busca na próxima leitura do arquivo.
Este é apenas um simples exemplo, mas que ilustra com clareza uma das vantagens de se mapear arquivos. Se houvesse uma simples função que recebesse o path de um arquivo e nos retornasse um ponteiro para o conteúdo dele, a busca seria bem simples.
Arquivos mapeados em memória também podem facilitar a escrita em seu conteúdo. Escrevendo no ponteiro recebido por tal mapeamento, o Memory Manager vai se encarregar de fazer o I/O necessário para que este novo conteúdo chegue ao disco.
Uma simples função de mapeamento
Aqui vou exemplificar o uso das rotinas que mapeiam um arquivo em memória. Os comentários seguem na explicação.
/****
*** MapFileToMemory
**
** Rotina que recebe o path de um arquivo que será
** mapeado em memória para leitura. Um endereço é
** retornado à rotina chamadora bem como o tamanho
** do arquivo.
*/
DWORD MapFileToMemory(LPCTSTR tzFileName,
LPVOID* ppMemory,
LPDWORD pdwSize)
{
HANDLE hFile = NULL,
hMapping = NULL;
DWORD dwError = ERROR_SUCCESS;
__try
{
__try
{
//-f--> Zera variáveis de saída.
*pdwSize = NULL;
*ppMemory = NULL;
//-f--> Aqui abrimos o arquivo a ser mapeado
hFile = CreateFile(tzFileName,
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
//-f--> Vericamos se o arquivo foi aberto, senão
// o homem do saco vem e nos leva.
if (hFile == INVALID_HANDLE_VALUE)
RaiseException(GetLastError(),
0,
0,
NULL);
//-f--> Embora o tamanho do arquivo não seja necessário
// nesta função, vamos aproveitar que temos o handle
// do arquivo em mãos para obter essa informação para
// a rotina chamadora que vai precisar dela.
*pdwSize = GetFileSize(hFile,
NULL);
//-f--> Aqui criamos um mapeamento do arquivo.
// Em kernel seria o equivalente a se criar uma
// section do arquivo.
hMapping = CreateFileMapping(hFile,
NULL,
PAGE_READONLY,
0,
0,
NULL);
//-f--> Prevenindo o homem do saco.
if (!hMapping)
RaiseException(GetLastError(),
0,
0,
NULL);
//-f--> Aqui sim o mapeamento é feito e ganhamos o
// intervalo de endereços que conterá o conteúdo
// do arquivo.
*ppMemory = MapViewOfFile(hMapping,
FILE_MAP_READ,
0,
0,
0);
//-f--> A mesma treta do saco que já comentei.
if (!*ppMemory)
RaiseException(GetLastError(),
0,
0,
NULL);
}
__finally
{
//-f--> Aqui é onde faremos toda a faxina
// fechando os handles que foram abertos.
if (hFile)
CloseHandle(hFile);
if (hMapping)
CloseHandle(hMapping);
}
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
//-f--> Oops! Alguma coisa não saiu como foi ensaiado.
// Encontre um culpado e faça de conta que não é com você.
dwError = GetExceptionCode();
}
return dwError;
}
Este exemplo é realmente bem simples, mas sinta-se à vontade para adicionar parâmetros que tornem essa função mais flexível e complexa.
“Fernando, mesmo que o arquivo tenha sido mapeado com succeso, você fecha o handles do arquivo e do mapeamento. Isso não deveria liberar as refências que este programa tem com o arquivo?”
Na verdade, depois de criarmos o mapeamento de arquivo utilizando a rotina CreateFileMapping() que recebe o handle do arquivo, uma referência extra já foi feita ao arquivo e assim já poderíamos fechar o handle dele se quisessemos. O mesmo acontece com a chamada da rotina MapViewOfFile(), que recebe o handle do mapeamento, e que por sua vez possui uma referência indireta ao arquivo mapeado. Ou seja, depois de tudo mapeado podemos fechar todos os handles e deixar as referências indiretas tomarem conta disso.
No próximo código fonte veremos um exemplo simples de utilização dessa função.
/****
*** _tmain
**
** Simples utilização da função de mapeamento de arquivo.
** Só pra não dizer que não fiz tudim tudim...
*/
int _tmain(int argc, _TCHAR* argv[])
{
PBYTE pBuffer;
DWORD dwError, dwSize, i;
//-f--> Passa o nome do arquivo e obtém o ponteiro
// com seu conteúdo mapeado. Simples assim...
dwError = MapFileToMemory(_T("C:\\Temp\\Test.txt"),
(LPVOID*)&pBuffer,
&dwSize);
//-f--> Testar erro nunca é demais.
if (dwError == ERROR_SUCCESS)
{
//-f--> Momentos de suspense antes de tocar o endereço.
printf("Hit any key to access the buffer at 0x%p...\n", pBuffer);
_getch();
//-f--> Imprime cada caractere armzenado no arquivo.
// "Olha mamãe! Sem o ReadFile()!"
for (i=0; i
printf("%c", pBuffer[i]);
//-f--> Aqui o mapeamento é desfeito.
UnmapViewOfFile(pBuffer);
}
return dwError;
}
Ao final deste exemplo podemos observar a chamada à rotina UnmapViewOfFile(), que recebe simplesmente o ponteiro base do mapeamento do arquivo. Com essa chamada, todas as referências internas são desfeitas e o arquivo finalmente é fechado.
Testando o brinquedo
Para que possamos fazer um teste besta, crie um arquivo texto utilizando o Notepad.exe.
Rodando a aplicação de teste temos a saída como ilustrada abaixo.
Agora na câmera lenta do replay
Com o WinDbg podemos observar o exato momento em que a aplicação acessa o intervalo de endereços referente ao conteúdo do arquivo. Para isso vamos colocar um breakpoint na rotina de leitura de arquivo do driver Ntfs.sys, desta forma poderemos ver a requisição do Memóry Manager ser atendida. Para que isso aconteça, o arquivo texto não pode estar no cache do sistema, então se você já rodou a aplicação de teste ao menos uma vez, você deverá reiniciar o sistema.
Caso você ainda não tenha utilizado o WinDbg e não sabe como conectá-lo ao sistema, então leia este post para um quick start. Depois de conectar o WinDbg ao Kernel do sistema, vá até o diretório onde está a aplicação de teste e a execute, mas ainda não pressione qualquer tecla deixando-a parada como mostra a seguir:
Depois disso pressione Ctrl+Break no WinDbg para que você adquira o controle sobre o sistema depurado, que neste momento vai permanecer congelado.
Para colocar o tal breakpoint na rotina de leitura de arquivo do Ntfs.sys, precisaremos saber onde está essa rotina dentro do driver. Podemos obter essa informação utilizando a extenção !drvobj do WinDbg como exibido abaixo.
kd> !drvobj \FileSystem\Ntfs 2
Driver object (843fd650) is for:
\FileSystem\Ntfs
DriverEntry: 828f5b75 Ntfs!GsDriverEntry
DriverStartIo: 00000000
DriverUnload: 00000000
AddDevice: 00000000
Dispatch routines:
[00] IRP_MJ_CREATE 8289400a Ntfs!NtfsFsdCreate
[01] IRP_MJ_CREATE_NAMED_PIPE 8165a013 nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE 82896fcf Ntfs!NtfsFsdClose
[03] IRP_MJ_READ 82818514 Ntfs!NtfsFsdRead
[04] IRP_MJ_WRITE 82815638 Ntfs!NtfsFsdWrite
[05] IRP_MJ_QUERY_INFORMATION 82895a88 Ntfs!NtfsFsdDispatchWait
[06] IRP_MJ_SET_INFORMATION 8281e950 Ntfs!NtfsFsdSetInformation
[07] IRP_MJ_QUERY_EA 82895a88 Ntfs!NtfsFsdDispatchWait
[08] IRP_MJ_SET_EA 82895a88 Ntfs!NtfsFsdDispatchWait
[09] IRP_MJ_FLUSH_BUFFERS 82884349 Ntfs!NtfsFsdFlushBuffers
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION 828b5fc6 Ntfs!NtfsFsdDispatch
[0b] IRP_MJ_SET_VOLUME_INFORMATION 828b5fc6 Ntfs!NtfsFsdDispatch
[0c] IRP_MJ_DIRECTORY_CONTROL 828b5d41 Ntfs!NtfsFsdDirectoryControl
[0d] IRP_MJ_FILE_SYSTEM_CONTROL 8289970e Ntfs!NtfsFsdFileSystemControl
[0e] IRP_MJ_DEVICE_CONTROL 82879466 Ntfs!NtfsFsdDeviceControl
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 8165a013 nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN 8282b36b Ntfs!NtfsFsdShutdown
[11] IRP_MJ_LOCK_CONTROL 82823b7a Ntfs!NtfsFsdLockControl
[12] IRP_MJ_CLEANUP 828a1d42 Ntfs!NtfsFsdCleanup
[13] IRP_MJ_CREATE_MAILSLOT 8165a013 nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY 828b5fc6 Ntfs!NtfsFsdDispatch
[15] IRP_MJ_SET_SECURITY 828b5fc6 Ntfs!NtfsFsdDispatch
[16] IRP_MJ_POWER 8165a013 nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL 8165a013 nt!IopInvalidDeviceRequest
[18] IRP_MJ_DEVICE_CHANGE 8165a013 nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA 82895a88 Ntfs!NtfsFsdDispatchWait
[1a] IRP_MJ_SET_QUOTA 82895a88 Ntfs!NtfsFsdDispatchWait
[1b] IRP_MJ_PNP 8286137b Ntfs!NtfsFsdPnp
Fast I/O routines:
FastIoCheckIfPossible 8288187b Ntfs!NtfsFastIoCheckIfPossible
FastIoRead 82880c38 Ntfs!NtfsCopyReadA
FastIoWrite 82881f53 Ntfs!NtfsCopyWriteA
FastIoQueryBasicInfo 82888c3a Ntfs!NtfsFastQueryBasicInfo
FastIoQueryStandardInfo 82888aa6 Ntfs!NtfsFastQueryStdInfo
FastIoLock 8287bf41 Ntfs!NtfsFastLock
FastIoUnlockSingle 8287bd75 Ntfs!NtfsFastUnlockSingle
FastIoUnlockAll 828cd7b3 Ntfs!NtfsFastUnlockAll
FastIoUnlockAllByKey 828cd958 Ntfs!NtfsFastUnlockAllByKey
ReleaseFileForNtCreateSection 8281e904 Ntfs!NtfsReleaseForCreateSection
FastIoQueryNetworkOpenInfo 8287ad84 Ntfs!NtfsFastQueryNetworkOpenInfo
AcquireForModWrite 8280c892 Ntfs!NtfsAcquireFileForModWrite
MdlRead 828cd0d8 Ntfs!NtfsMdlReadA
MdlReadComplete 81650af6 nt!FsRtlMdlReadCompleteDev
PrepareMdlWrite 828cd31f Ntfs!NtfsPrepareMdlWriteA
MdlWriteComplete 817f5a9a nt!FsRtlMdlWriteCompleteDev
FastIoQueryOpen 82874d03 Ntfs!NtfsNetworkOpenCreate
AcquireForCcFlush 8281ab35 Ntfs!NtfsAcquireFileForCcFlush
ReleaseForCcFlush 8281aa9c Ntfs!NtfsReleaseFileForCcFlush
Como você deve estar imaginando, a rotina de leitura do Ntfs é utilizada com muita frequência, o que faria este breakpoint parar muitas vezes sem ter a menor relação com o nosso teste. Para limitar o escopo do breakpoint, vamos fazer com que ele se aplique somente à thread que fará a solicicação que estamos esperando.
Como já expliquei no post anterior, quando o endereço de memória é obtido, o arquivo ainda não foi lido. Quando a aplicação desreferenciar este ponteiro buscando os dados, um page fault será gerado e o Memory Manager vai tomar o controle sobre a thread por meio de um trap de sistema. Essa é a thread que será utilizada para realizar a leitura do arquivo que vai abastecer a página de memória à pedido do Memory Manager. Esta é a razão pela qual nosso programa de teste espera uma tecla ser pressionada antes de acessar o buffer. Isso nos dá a oportunidade de obter a identificação da thread que está aguardando esse evento.
Utilizamos a extenção !process para localizar o nosso programa de teste e também listará suas threads, que em nosso caso é uma única.
kd> !process 0 2 MapFile.exe
PROCESS 84bf6d90 SessionId: 1 Cid: 0b60 Peb: 7ffdf000 ParentCid: 0b40
DirBase: 1f09b4c0 ObjectTable: 8e77ccd0 HandleCount: 5.
Image: MapFile.exe
THREAD 84f6cb50 Cid 0b60.0b64 Teb: 7ffde000 Win32Thread: 00000000 WAIT: (WrLpcReply) ...
84f6cd64 Semaphore Limit 0x1
kd> bp /1 /t 84f6cb50 Ntfs!NtfsFsdRead
kd> g
Depois de colocado o breakpoint, podemos liberar a execução do sistema e teclar algo na aplicação de teste. Isso fará com que nosso breakpoint interrompa o sistema bem como pretendíamos. Olhando para a pilha de chamadas que temos no momento, podemos evidenciar a execução do trap que foi gerado pela aplicação de teste. Este trap está sendo atendido pelo Memory Manager.
Breakpoint 0 hit
Ntfs!NtfsFsdRead:
82818514 6a40
kd> kb
ChildEBP RetAddr Args to Child
8f395b6c 816f00c3 84438020 84f40290 84f40290 Ntfs!NtfsFsdRead
8f395b84 821a3ba7 84437730 84f40290 00000000 nt!IofCallDriver+0x63
8f395ba8 821a3d64 8f395bc8 84437730 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x251
8f395be0 816f00c3 84437730 84f40290 00000000 fltmgr!FltpDispatch+0xc2
8f395bf8 8167bf2e 84f6cb50 8443a18c 8443a158 nt!IofCallDriver+0x63
8f395c14 816b8d51 00000043 84f6cb50 8443a198 nt!IoPageRead+0x172
8f395cd0 816db03f 00020000 90825810 00000000 nt!MiDispatchFault+0xd18
8f395d4c 8168ebf4 00000000 00020000 00000001 nt!MmAccessFault+0x1fb7
8f395d4c 0018d972 00000000 00020000 00000001 nt!KiTrap0E+0xdc
0015fbc0 0018ec36 00000001 00281a28 00281a78 MapFile!wmain+0x72
0015fc0c 0018eb0f 0015fc20 77554911 7ffdf000 MapFile!__tmainCRTStartup+0x116
0015fc14 77554911 7ffdf000 0015fc60 77ace4b6 MapFile!wmainCRTStartup+0xf
0015fc20 77ace4b6 7ffdf000 77a26775 00000000 kernel32!BaseThreadInitThunk+0xe
0015fc60 77ace489 0018b532 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x23
0015fc78 00000000 0018b532 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b
Como conhecemos o protótipo que uma rotina de dispatch precisa ter, sabemos que o segundo parâmetro da rotina NtfsFsdRead() é o endereço da IRP que o driver recebeu. Utilizando a extensão !irp podemos obter detalhes sobre a IRP. Isso nos permite conhecer o FileObject ao qual está destinado essa solicitação.
kd> !irp 84f40290
Irp is active with 8 stacks 8 is current (= 0x84f403fc)
Mdl=8443a1d8: No System Buffer: Thread 84f6cb50: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
>[ 3, 0] 0 0 84438020 84bd0028 00000000-00000000
\FileSystem\Ntfs
Args: 00001000 00000000 00000000 00000000
Com o endereço do FileObject em mãos, a extensão !fileobj nos mostrará mais detalhes sobre esse objeto. Assim podemos verificar que de fato o arquivo a ser lido é o nosso arquivo texto que foi mapeado.
kd> !fileobj 84bd0028
\Temp\Test.txt
Device Object: 0x84439030 \Driver\volmgr
Vpb: 0x84436e28
Access: Read SharedRead SharedDelete
Flags: 0x44042
Synchronous IO
Cache Supported
Cleanup Complete
Handle Created
FsContext: 0x92a4cd80 FsContext2: 0x92a4ced8
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: 84d24e74
Shared Cache Map: 00000000
Sabendo que estamos no contexto da thread que fez o acesso, podemos dar uma espiadinha no endereço acessado antes do page fault ser atendido. Esse endereço foi exibido na saída da aplicação de teste antes o breakpoint interromper a execução do sistema.
kd> db 0x00020000
00020000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
00020070 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
“Fernando, por que aparecem sinais de interrogação? Tudo bem que o conteúdo do arquivo ainda não foi copiado para o buffer da aplicação, mas não deveríamos ver lixo ou mesmo zeros?”
Olha, essa sua pergunta foi realmente muito boa, acho que eu mesmo não poderia ter pensado em uma pergunta melhor. Na verdade a resposta para essa pergunta está vinculada àquela reposta tosca do post anterior. O que acontece é que um intervalo de endereços foi reservado para conter as páginas de memória com o conteúdo do arquivo. Como nenhum acesso ainda foi feito, o esse endereço virtual ainda não aponta para nenhuma página física de memória. Sem essa página física não se pode determinar seus dados. Podemos verificar isso utilizando a extenção !vtop do WinDbg, que faz a tradução de endereços virtuais para endereços físicos.
kd> !vtop 0 0x00020000
X86VtoP: Virt 00020000, pagedir 1f09b4c0
X86VtoP: PAE PDPE 1f09b4c0 - 000000001876d801
X86VtoP: PAE PDE 1876d000 - 0000000018908867
X86VtoP: PAE PTE 18908100 - ffffffff00000420
X86VtoP: Virt ffffffff, pagedir 1f09b4c0
X86VtoP: PAE PDPE 1f09b4d8 - 00000000187b0801
X86VtoP: PAE PDE 187b0ff8 - 0000000000128063
X86VtoP: PAE PTE 128ff8 - 0000000000000000
X86VtoP: PAE zero PTE
Virtual address 20000 translation fails, error 0x8007001E.
kd> !error 0x8007001E
Error code: (HRESULT) 0x8007001e (2147942430) - The system cannot read from the specified device.
A tentativa de tradução desse endereço virtual resulta em um erro. Vamos tentar fazer essa tradução novamente depois que o page fault for atendito. Vamos liberar a execução do sistema até o endereço de retorno para a rotina MmAccessFault(). Este endereço foi obtido na pilha de chamadas da thread e foi destacado nos resultados do comando kd já ilustrado acima.
kd> ga 8168ebf4
nt!KiTrap0E+0xdc:
8168ebf4 85c0 test eax,eax
kd> !vtop 0 0x00020000
X86VtoP: Virt 00020000, pagedir 1f09b4c0
X86VtoP: PAE PDPE 1f09b4c0 - 000000001876d801
X86VtoP: PAE PDE 1876d000 - 0000000018908867
X86VtoP: PAE PTE 18908100 - 8000000018844025
X86VtoP: PAE Mapped phys 18844000
Virtual address 20000 translates to physical address 18844000.
Aqui o page fault já foi antendido e o controle será devolvido à aplicação. Neste ponto o Memory Manager realizou as tarefas necessárias para que esse endereço virtual agora pudesse ser traduzido para uma página física. Repetindo a mesma tentativa de tradução que falhou anteriormente, teremos a seguinte saída.
kd> db 0x00020000
00020000 54 65 73 74 65 20 64 65-20 6d 61 70 65 61 6d 65 Teste de mapeame
00020010 6e 74 6f 20 64 65 20 61-72 71 75 69 76 6f 2e 2e nto de arquivo..
00020020 2e 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00020030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00020040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00020050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00020060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00020070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
Liberando a execução do sistema, a aplicação fará o acesso ao buffer e teremos a mesma saída exibida anteriormente. Vale lembrar que para repetir essa experiência, é necessário reiniciar o sistema, pois o conteúdo do arquivo texto agora está no cache do sistema. Isso significa que o page fault não ocorrerá novamente até que esta página seja descartada pelo Cache Manager. Tal evento depende de muitos fatores e pode não acontecer até que a máquina desligue.
Enfim, este post além de trazer uma simples função de mapeamento de arquivo, também traz o mesmo blá-blá-blá técnico de sempre. Espero que tenham gostado.
Até mais! 😉
Este artigo está lindo de morrer! Parabéns!
Há alguma possibilidade de vermos artigos futuros indo um pouco mais a fundo o processo de exceção junto da manipulação que é realizada pelo Cache Manager? Podemos, por exemplo, acompanhar o fluxo em assembly/pseudoassembly entre o Cache e o Memory Manager até voltarmos para o NTFS driver? Ou isso faria o blogue passar seus limites para engenharia reversa?
[]s
Olá Lesma, valeu pelos comentários.
Receio que você não verá maiores níveis de detalhes em operações como essa em meu blog.
Meu principal objetivo aqui é demonstrar como a arquitetura do Windows aplica suas regras e quais os passos para se conseguir serviços dela. Entrar neste nível de punhetagem iria além do que proponho aqui, ainda correndo o risco de ter um post ainda mais longo com pouco ganho prático.
De qualquer forma, isso não significa que não podemos discutir o assunto ou ainda irmos debug a dentro em eventuais encontros.
Um Abraço.