Windows 11 NVMe: Driver Nativo vs. Fabricante e o Mito da Tradução SCSI
Seu NVMe aparece como SCSI? Entenda a pilha de armazenamento do Windows (Storport), por que drivers de fabricantes (Samsung/WD) estão morrendo e o impacto real de stornvme.sys na latência.
Você acabou de instalar um SSD NVMe Gen4 ou Gen5. O hardware promete velocidades de transferência absurdas e latências de microssegundos. Você roda um benchmark e os números não batem com a caixa, ou pior, o sistema parece engasgar sob carga pesada. O instinto imediato de qualquer entusiasta ou sysadmin veterano é: "A culpa é do driver da Microsoft. Preciso baixar o driver da Samsung/Western Digital".
Pare. Como investigador forense de sistemas, aprendi que assumir a culpa antes de analisar a cena do crime é o caminho mais rápido para um diagnóstico errado.
A realidade do subsistema de armazenamento no Windows 11 mudou drasticamente. A era de ouro dos drivers proprietários está acabando, e o verdadeiro gargalo raramente é quem está "dirigindo" o SSD, mas sim as camadas de segurança e abstração que o sistema operacional empilha antes mesmo do comando chegar ao hardware. Vamos dissecar o que acontece quando você grava um arquivo, isolar as variáveis e entender por que o driver nativo (stornvme.sys) venceu a guerra.
O Dilema do Driver NVMe no Windows
Resumo Executivo: O driver nativo do Windows (
stornvme.sys) atua como um tradutor entre a pilha de armazenamento legada do Windows (baseada em SCSI) e o protocolo moderno NVMe. Embora drivers de fabricantes (Samsung, Solidigm) historicamente oferecessem melhor desempenho ao otimizar essa tradução, a evolução do padrão NVMe e as otimizações da Microsoft tornaram o driver nativo a escolha preferencial para estabilidade e compatibilidade com recursos modernos como DirectStorage, tornando os drivers proprietários obsoletos para a maioria dos casos de uso.
A Ilusão do SCSI: Entendendo a Camada Storport no Windows
Para entender por que existe um debate sobre drivers, precisamos olhar para a pilha de armazenamento do Windows. Se você abrir o Gerenciador de Dispositivos agora e olhar as propriedades do seu NVMe de última geração, verá referências a "SCSI". Por que um protocolo desenhado para memória não-volátil (NVMe) está sendo tratado como um disco rígido de servidor de 1995?
O Windows ama retrocompatibilidade. O núcleo do subsistema de armazenamento é o Storport (storport.sys). Ele fala a língua dos SRBs (SCSI Request Blocks). O problema é que o NVMe não fala SCSI; ele fala em filas de submissão e conclusão (Submission/Completion Queues) direto no barramento PCIe.
Figura: A Pilha de Armazenamento do Windows (Storage Stack): Onde o NVMe encontra o legado do SCSI.
Aqui reside o "Mito da Tradução". Todo driver NVMe no Windows — seja o nativo da Microsoft ou um proprietário da Samsung — precisa operar como um "Miniport Driver" abaixo do Storport.
O Windows envia um comando de leitura (SCSI Read).
O driver recebe esse comando SCSI.
O driver traduz o SCSI para um comando NVMe.
O driver coloca o comando na fila do SSD.
Durante anos, o argumento para usar drivers de terceiros era que a Microsoft fazia essa tradução de forma ineficiente ("lazy translation"), enquanto a Samsung ou Intel (agora Solidigm) faziam uma tradução otimizada, reduzindo o overhead de CPU. Hoje, essa diferença é marginal em 99% dos cenários de desktop e workstation.
Anatomia do stornvme.sys: O Driver Nativo da Microsoft
O stornvme.sys não é mais o driver genérico "quebra-galho" que era no Windows 7 ou 8.1. No Windows 10 e 11, ele foi reescrito para suportar as complexidades do NVMe 1.4 e 2.0.
O que o driver nativo faz bem?
Gerenciamento de Energia (APST): O driver nativo é extremamente agressivo e correto ao colocar o SSD em estados de baixa energia (L1.2) quando ocioso. Drivers proprietários antigos frequentemente desativavam isso para ganhar milissegundos em benchmarks sintéticos, ao custo de aquecer seu laptop.
HMB (Host Memory Buffer): Para SSDs DRAM-less, o driver nativo gerencia a alocação de RAM do sistema de forma transparente.
Segurança: Integração total com BitLocker e Encrypted Hard Drive (eDrive) sem as falhas de implementação que vimos em drivers antigos da Crucial ou Samsung no passado.
O "custo" do driver nativo é a adesão estrita aos padrões. Se o seu SSD tem um firmware "criativo" que viola levemente a especificação NVMe para ganhar performance, o stornvme.sys pode rejeitar comandos ou causar um reset no dispositivo. O driver do fabricante, conhecendo seus próprios "truques", mascararia isso.
O Fim dos Drivers Proprietários: Por que o mercado mudou
Você notou que é cada vez mais difícil encontrar drivers dedicados para SSDs novos? A Samsung, com a série 990 Pro, recomenda explicitamente o uso do driver da Microsoft. A Western Digital faz o mesmo. A Intel vendeu sua divisão para a Solidigm, que ainda mantém um driver, mas seu foco é enterprise.
Por que os fabricantes desistiram?
Custo de Manutenção vs. Retorno: Manter um driver de kernel (
.sys) assinado pela Microsoft (WHQL) é caro e arriscado. Um bug no driver causa uma Tela Azul da Morte (BSOD). O ganho de performance (1-3% em IOPS aleatórios) não justifica o risco de estabilidade.DirectStorage e Bypass: Novas APIs de jogos começam a contornar a pilha legada (veja abaixo), tornando a otimização da tradução SCSI irrelevante.
Atualizações do Windows: A Microsoft muda o kernel com frequência. Drivers proprietários quebravam funcionalidades como "Modern Standby" ou hibernação constantemente.
Comparativo Técnico: Nativo vs. Proprietário
| Característica | Driver Nativo (Microsoft stornvme) | Driver Proprietário (Samsung/Solidigm/WD) |
|---|---|---|
| Estabilidade | Alta (Testado em bilhões de máquinas) | Média (Foco em performance, risco de BSOD) |
| Latência (Idle) | Otimizada para economia de energia | Otimizada para resposta rápida (gasta mais bateria) |
| Compatibilidade | Suporte total a BitLocker, VBS, DirectStorage | Pode conflitar com VBS ou Core Isolation |
| Atualizações | Automáticas via Windows Update | Manual (requer usuário proativo) |
| Feature Set | Padrão NVMe Estrito | Pode habilitar recursos "fora do padrão" ou diagnósticos avançados |
DirectStorage e Bypass de IO: Onde o driver importa (e onde não)
Se o seu objetivo é performance em jogos modernos ou aplicações de workstation pesadas, você precisa entender que o modelo de I/O está mudando.
O DirectStorage é a tentativa da Microsoft de admitir que a pilha SCSI/Storport é lenta demais para NVMe. Em jogos compatíveis, o DirectStorage cria um caminho paralelo que ignora grande parte da burocracia do sistema operacional, permitindo que a GPU ou a CPU acessem os dados comprimidos do SSD de forma muito mais direta.
Neste cenário, o driver proprietário muitas vezes atrapalha. O stornvme.sys é a referência para a qual o DirectStorage foi otimizado. Drivers de terceiros que tentam interceptar chamadas ou fazer seu próprio gerenciamento de fila podem introduzir latência ou incompatibilidade com esse bypass.
Os Verdadeiros Vilões de Performance: VBS, HVCI e BitLocker
Aqui entra a análise forense. Você mediu uma queda de 15% na performance de gravação aleatória 4K (RND4K Q1T1) e está culpando o driver. Mas ao investigar a "cena do crime" (o Gerenciador de Tarefas e Monitor de Desempenho), vemos algo interessante: alta utilização de CPU pelo processo System durante o teste.
O culpado não é o armazenamento. É a segurança.
Figura: O verdadeiro impacto na latência: Driver vs. Camadas de Segurança (VBS).
1. VBS e HVCI (Isolamento de Núcleo)
O Windows 11 habilita por padrão a Segurança Baseada em Virtualização (VBS). Isso significa que seu kernel roda dentro de um contêiner virtualizado. Cada operação de I/O intensa exige trocas de contexto (context switches) pesadas para verificar a integridade da memória.
Sintoma: Queda drástica em IOPS aleatórios e aumento de latência.
Diagnóstico: Desativar temporariamente a "Integridade de Memória" restaura a velocidade (mas reduz a segurança).
2. BitLocker (Software vs. Hardware)
O driver nativo suporta criptografia por hardware (se o SSD suportar), mas o padrão do Windows é usar criptografia por software (XTS-AES 128) para garantir que não haja backdoors no firmware do SSD.
- Impacto: O driver nativo precisa esperar a CPU criptografar/descriptografar os dados antes de enviar ao NVMe. Isso adiciona latência que nenhum driver mágico da Samsung pode resolver.
Metodologia de Teste: Como medir latência real
Pare de usar o CrystalDiskMark para diagnosticar problemas de latência fina. Ele é excelente para ver se o drive atinge a velocidade máxima sequencial ("O marketing mentiu?"), mas péssimo para entender a interação Driver vs. OS.
Para uma análise forense, usamos o DISKSPD (ferramenta de linha de comando da Microsoft). Precisamos medir não apenas a taxa de transferência, mas a latência de percentil 99.9 (o soluço que trava seu sistema).
O Teste de Latência Real
Abra o PowerShell como Administrador e execute este comando (ajuste # para o número do seu disco físico, use Get-PhysicalDisk para achar):
# Teste de Latência de Leitura Aleatória 4K (O teste "tortura" de responsividade)
# -d30: Duração de 30 segundos
# -b4K: Blocos de 4KB
# -r: Acesso aleatório
# -o1: Queue Depth de 1 (Simula uso real de desktop, não servidor)
# -t1: 1 Thread
# -L: Medir latência
# -D: Desabilitar cache de software (Direct IO)
diskspd.exe -d30 -b4K -r -o1 -t1 -L -D #<NúmeroDoDisco>
O que procurar no resultado:
Avg Latency: Deve estar abaixo de 0.050 ms (50 microssegundos) para um NVMe Gen4 saudável.
99.9th percentile: Se este número for alto (ex: > 5ms), você tem um problema de driver, firmware ou interferência de software (antivírus/VBS), independentemente do driver que estiver usando.
Veredito Forense
Se você está em dúvida entre o driver nativo e o do fabricante:
Fique com o Nativo (
stornvme.sys) se você usa Windows 11, preza por estabilidade, usa DirectStorage ou tem um SSD moderno (2022+).Use o do Fabricante APENAS se você tiver um hardware específico legado (ex: Samsung 970 EVO Plus) que apresenta bugs conhecidos com o driver nativo, ou se precisar de recursos de gerenciamento específicos que o software do fabricante exige.
A era de "tunar" drivers de armazenamento acabou. O foco agora deve ser na configuração correta das camadas de segurança e na integridade do hardware.
Referências & Leitura Complementar
NVM Express Base Specification 2.0: Detalhes técnicos sobre filas de submissão/conclusão e o fim da necessidade de tradução complexa.
Microsoft Docs - Storport Driver: "History of the Storport Driver and NVMe support in Windows".
DirectStorage API Overview: Documentação técnica sobre como o bypass de pilha funciona (Microsoft Game Stack).
DISKSPD Documentation: GitHub oficial da Microsoft com parâmetros de teste de carga sintética.
Otávio Henriques
Arquiteto de Soluções Enterprise
"Com duas décadas desenhando infraestruturas críticas, olho além do hype. Foco em TCO, resiliência e trade-offs, pois na arquitetura corporativa a resposta correta quase sempre é 'depende'."