Você configura o Windows 11 para desligar a tela e entrar em suspensão depois de alguns minutos, deixa o computador parado e volta algum tempo depois.

A tela pode até apagar.

Mas o computador continua ligado.

Ventoinhas continuam funcionando, LEDs permanecem acesos e o equipamento aparentemente nunca entra no estado de suspensão esperado.

Em outro cenário, você escolhe manualmente:

Iniciar → Energia → Suspender

e alguns segundos depois percebe que o computador continua funcionando normalmente.

É comum começar tentando soluções aleatórias:

• alterar o plano de energia;
• reiniciar o computador;
• atualizar todos os drivers;
• desativar dispositivos;
• desligar inicialização rápida;
• mudar configurações de USB;
• executar SFC;
• alterar BIOS;
• restaurar configurações de energia.

O problema é que essas ações não respondem à pergunta mais importante:

o que está impedindo o Windows 11 de entrar em suspensão?

O próprio Windows possui ferramentas capazes de fornecer pistas sobre programas, drivers e componentes que estão solicitando que o computador permaneça ativo.

Uma das mais importantes é:

powercfg

Com ela podemos investigar diferentes aspectos do gerenciamento de energia por meio de comandos como:

powercfg /requests
powercfg /devicequery wake_armed
powercfg /waketimers
powercfg /a
powercfg /lastwake
powercfg /sleepstudy
powercfg /systemsleepdiagnostics

Mas esses comandos não respondem exatamente à mesma pergunta.

Antes de executá-los, precisamos determinar qual problema realmente está acontecendo.

---

Primeiro: “não suspende” e “acorda sozinho” não são a mesma coisa

Essa é provavelmente a distinção mais importante deste guia.

Compare:

Situação A

Windows funcionando
↓
usuário solicita suspensão
↓
computador não entra em suspensão

com:

Situação B

Windows funcionando
↓
entra em suspensão
↓
permanece suspenso
↓
algum evento ocorre
↓
computador acorda

Visualmente, os dois problemas podem parecer semelhantes.

O usuário volta para o computador e encontra:

PC ligado

Mas tecnicamente são situações diferentes.

---

Problema 1 — algo impede a entrada em suspensão

Neste cenário, algum componente pode manter uma solicitação de energia ativa.

Exemplo conceitual:

programa
↓
solicitação de energia
↓
Windows permanece ativo

Pode envolver:

• reprodução de mídia;
• áudio;
• driver;
• compartilhamento;
• processo;
• serviço;
• dispositivo;
• atividade específica do sistema.

Uma das primeiras ferramentas para investigar isso será:

powercfg /requests

---

Problema 2 — o computador suspende e acorda depois

Aqui a suspensão aconteceu.

Mas posteriormente algo despertou o sistema.

Exemplo:

PC suspende
↓
placa de rede recebe evento
↓
PC acorda

ou:

PC suspende
↓
timer programado
↓
PC acorda

Nesse caso, outros comandos ganham importância:

powercfg /lastwake

powercfg /waketimers

e:

powercfg /devicequery wake_armed

Portanto, executar apenas /requests em qualquer problema de suspensão pode levar a uma investigação incompleta.

---

Problema 3 — a tela apaga, mas isso não significa que o PC suspendeu

Existe ainda uma terceira confusão muito comum.

O usuário observa:

monitor apagado

e conclui:

computador suspendeu

Mas desligar a tela e suspender o sistema são ações diferentes.

O Windows pode:

desligar tela
↓
continuar funcionando

Isso é completamente possível.

---

Tela desligada não é prova de suspensão

O plano de energia pode estar configurado, por exemplo, para:

Desligar tela após 5 minutos

e:

Suspender após 30 minutos

Entre esses momentos:

monitor apagado
+
Windows ativo

é o comportamento esperado.

Por isso, não use apenas a tela como indicador.

---

Como saber se o computador realmente suspendeu?

Dependendo do equipamento e do tipo de suspensão suportado, sinais físicos podem variar.

Por exemplo:

• LEDs podem mudar;
• ventoinhas podem parar;
• consumo pode diminuir;
• atividade do sistema muda;
• determinados dispositivos entram em estado de baixo consumo.

Mas computadores modernos também podem utilizar arquiteturas de energia diferentes do modelo clássico que muitos usuários conhecem.

Por isso, precisamos consultar o próprio Windows.

---

Descubra quais estados de suspensão o computador suporta

Abra o Terminal, Prompt de Comando ou PowerShell como administrador quando necessário e execute:

powercfg /a

Esse é um dos primeiros comandos que eu utilizaria neste diagnóstico.

Ele mostra quais estados de suspensão estão disponíveis no sistema.

---

O que powercfg /a responde?

Ele ajuda a responder:

“Quais estados de energia este computador realmente suporta?”

Isso é muito diferente de perguntar:

“Qual programa está impedindo a suspensão?”

Por isso:

powercfg /a

é uma ferramenta de contexto.

---

Estados de energia não são iguais em todos os computadores

Dependendo do hardware, firmware e configuração, o Windows pode apresentar suporte a diferentes estados.

Historicamente encontramos conceitos como:

S0
S1
S2
S3
S4
S5

Mas computadores modernos podem utilizar Modern Standby, alterando bastante a forma como o usuário percebe a suspensão.

---

O que é S0?

Simplificando, S0 representa o estado de funcionamento.

O computador está operacional.

---

O que é S3?

S3 é associado ao modelo clássico de suspensão que muitos usuários conhecem.

Conceitualmente:

CPU e vários componentes reduzem atividade
↓
RAM preserva estado
↓
consumo cai significativamente

O retorno tende a ser rápido.

---

O que é S4?

S4 está relacionado à hibernação.

Nesse cenário, o estado da sessão pode ser preservado em armazenamento para permitir retomada posterior.

---

E o S5?

S5 representa o estado de desligamento lógico conhecido como soft off.

Isso já não é a mesma coisa que suspensão.

---

O que é Modern Standby?

Em muitos computadores modernos, especialmente notebooks, podemos encontrar Modern Standby.

Nesse modelo, o sistema utiliza uma abordagem diferente da suspensão S3 tradicional.

O equipamento pode permanecer em um estado de baixo consumo mantendo determinadas capacidades do sistema.

Isso pode confundir quem espera que todo notebook moderno se comporte exatamente como um computador antigo entrando em S3.

---

Como descobrir se o PC utiliza Modern Standby?

Novamente:

powercfg /a

é uma das primeiras referências.

Leia o resultado em vez de assumir qual arquitetura o equipamento utiliza.

---

Não tente “ativar S3” seguindo qualquer tutorial

Existem muitos procedimentos na Internet que sugerem alterações no Registro ou firmware para tentar forçar estados de suspensão.

Isso pode não ser suportado pelo hardware, firmware ou implementação do fabricante.

O correto é começar verificando:

hardware
+
firmware
+
estados anunciados ao Windows

e não presumir que todo computador precisa oferecer exatamente os mesmos estados.

---

Agora vamos ao comando principal: powercfg /requests

Execute:

powercfg /requests

Esse comando é extremamente útil quando o problema é:

o Windows deveria suspender, mas alguma solicitação está mantendo o sistema ativo.

---

O que o powercfg /requests procura?

Ele exibe solicitações de energia ativas feitas por aplicativos e drivers.

Dependendo do sistema e do momento, você poderá encontrar categorias relacionadas a:

DISPLAY
SYSTEM
AWAYMODE
EXECUTION
PERFBOOST
ACTIVELOCKSCREEN

A disponibilidade e o conteúdo podem variar.

---

Exemplo de saída sem bloqueadores aparentes

Você pode executar:

powercfg /requests

e encontrar categorias sem solicitações ativas.

Isso significa que naquele momento o comando não encontrou uma solicitação correspondente nas categorias exibidas.

Mas isso não prova automaticamente:

“Não existe nenhum problema de suspensão.”

Pode ser necessário investigar outras causas e, principalmente, reproduzir o problema no momento certo.

---

Execute /requests enquanto o problema está acontecendo

Esse detalhe é fundamental.

Imagine que um programa faz:

inicia reprodução
↓
cria solicitação
↓
termina reprodução
↓
remove solicitação

Se você executar:

powercfg /requests

depois que a atividade terminou, talvez não veja a solicitação.

O diagnóstico deve observar o estado enquanto o problema está presente.

---

Exemplo: aplicativo mantém SYSTEM ativo

Uma saída pode indicar uma solicitação associada a um processo ou componente.

Conceitualmente:

SYSTEM:
[PROCESS] \Device\HarddiskVolume...\Programa.exe

Isso merece investigação.

Não significa automaticamente que o programa está com defeito.

Talvez ele esteja executando uma atividade que legitimamente exige que o sistema permaneça acordado.

---

Por que um programa pediria para o PC permanecer ativo?

Imagine um aplicativo executando:

• apresentação;
• reprodução de mídia;
• gravação;
• tarefa longa;
• operação que não deveria ser interrompida.

Nesses casos, impedir temporariamente a suspensão pode ser comportamento intencional.

O problema aparece quando:

atividade terminou
↓
solicitação permanece

ou quando o usuário não espera aquele comportamento.

---

Solicitação de DISPLAY e SYSTEM não significam exatamente a mesma coisa

Uma solicitação relacionada a:

DISPLAY

pode estar ligada à necessidade de manter a tela ativa.

Uma solicitação relacionada a:

SYSTEM

pode estar relacionada à necessidade de manter o sistema em funcionamento.

Por isso, leia a categoria.

Não veja apenas o nome do programa.

---

Um driver também pode aparecer

Nem toda solicitação vem de um aplicativo convencional.

Podemos encontrar componentes relacionados a drivers.

Isso muda a investigação.

Exemplo conceitual:

[DRIVER]
componente de áudio

Nesse caso, fechar aplicativos aleatoriamente talvez não resolva.

Precisamos descobrir por que o driver mantém a solicitação.

---

Áudio é um excelente exemplo

Imagine:

aplicativo
↓
stream de áudio
↓
driver de áudio
↓
solicitação de energia

O usuário fecha a janela principal, mas algum componente continua com atividade de áudio.

O resultado pode aparecer no diagnóstico de energia.

---

Não desative o dispositivo imediatamente

Se /requests mostrar algo relacionado a áudio, rede ou outro driver, não faça:

Gerenciador de Dispositivos
↓
Desativar

como primeira ação.

Descubra primeiro:

• qual aplicativo está usando o componente;
• se existe stream ativo;
• se o driver está atualizado;
• se o comportamento é reproduzível.

---

Teste A/B é extremamente útil

Imagine:

Aplicativo aberto
↓
powercfg /requests
↓
SYSTEM ativo

Feche corretamente o aplicativo.

Execute novamente:

powercfg /requests

Se a solicitação desapareceu, temos uma correlação.

Depois abra novamente e repita.

Se:

abre programa
→ solicitação aparece

fecha programa
→ solicitação desaparece

temos uma evidência muito melhor.

---

Fechar janela pode não encerrar o processo

Esse ponto apareceu em outros diagnósticos do Windows e também importa aqui.

Um programa pode funcionar assim:

clicar X
↓
janela fecha
↓
processo continua na bandeja

Portanto, depois de fechar a janela, confira o Gerenciador de Tarefas.

---

Descubra qual processo está realmente ativo

Use:

Ctrl + Shift + Esc

ou PowerShell:

Get-Process

Se o /requests indicar um executável específico, localize esse processo.

---

Identifique caminho e fabricante

No Process Explorer ou propriedades do arquivo, verifique:

• caminho;
• empresa;
• versão;
• assinatura.

No PowerShell, você também pode usar:

Get-AuthenticodeSignature "C:\Caminho\Programa.exe"

Isso ajuda a identificar corretamente o componente.

---

Não confunda solicitação de energia com alto uso de CPU

Um processo pode estar usando:

0% ou quase 0% CPU

e ainda manter uma solicitação de energia.

Da mesma forma, um processo usando CPU não significa automaticamente que ele bloqueia a suspensão.

São métricas diferentes.

---

“Meu PC está parado” não significa que o Windows está ocioso

Visualmente, você pode não estar mexendo em nada.

Mas o sistema pode ter:

• mídia;
• sincronização;
• atividade de dispositivo;
• serviço;
• aplicação em segundo plano.

Por isso usamos ferramentas de diagnóstico em vez de apenas observar a tela.

---

O Gerenciador de Tarefas sozinho não responde tudo

Ele ajuda a descobrir:

quem está executando

Mas não necessariamente:

quem está fazendo uma solicitação de energia

É aí que:

powercfg /requests

se torna tão importante.

---

O que fazer se /requests mostrar um processo?

Não comece encerrando à força.

Faça:

identifique o programa
↓
descubra a atividade
↓
feche corretamente
↓
execute /requests novamente
↓
teste suspensão

Se o problema desaparecer, temos uma hipótese forte.

---

O que fazer se mostrar um driver?

Faça:

identifique dispositivo
↓
identifique fabricante
↓
descubra software relacionado
↓
verifique atividade
↓
teste de forma controlada

Atualizar driver pode ser apropriado em determinados casos, mas não deve ser a primeira resposta automática para qualquer linha exibida.

---

E se powercfg /requests não mostrar nada?

Esse é um cenário importante.

Imagine:

powercfg /requests

e nenhuma solicitação relevante aparece.

Mesmo assim o PC aparentemente não suspende.

Agora precisamos perguntar:

ele realmente tentou suspender?

Talvez:

• configuração de suspensão esteja diferente;
• plano de energia tenha sido alterado;
• o PC use Modern Standby;
• exista um comportamento relacionado a dispositivo;
• o problema seja despertar, não entrada em suspensão;
• a solicitação tenha desaparecido antes da consulta.

---

Verifique as configurações de suspensão

Abra as configurações de energia do Windows e confirme os tempos definidos para:

• tela;
• suspensão.

Não presuma que continuam como você configurou meses atrás.

---

Planos e configurações podem ter sido alterados

Atualizações, softwares de fabricante e utilitários podem modificar comportamentos de energia.

Podemos consultar configurações através do próprio powercfg.

---

Veja o esquema de energia ativo

Execute:

powercfg /getactivescheme

Isso ajuda a descobrir qual esquema está ativo naquele momento.

---

Liste os esquemas disponíveis

Execute:

powercfg /list

ou:

powercfg /l

Você poderá visualizar os esquemas disponíveis.

---

Não restaure planos de energia antes de coletar evidências

Comandos que restauram configurações podem eliminar justamente a condição que você deveria diagnosticar.

Primeiro registre:

estado atual
↓
problema
↓
evidências

Depois altere.

---

powercfg /requests deve fazer parte de uma sequência

Uma boa sequência inicial é:

powercfg /a

Depois:

powercfg /getactivescheme

Depois:

powercfg /requests

Esses três comandos respondem perguntas diferentes:

/a
→ quais estados de suspensão existem?

/getactivescheme
→ qual esquema está ativo?

/requests
→ existem solicitações de energia ativas?

---

Agora precisamos descobrir se o computador acordou

Se você suspeita que ele chegou a suspender e voltou sozinho, execute:

powercfg /lastwake

Esse comando pertence a outra etapa do diagnóstico.

Ele tenta fornecer informações relacionadas ao último evento de despertar.

---

Não use /lastwake para provar que o PC nunca suspendeu

Se o problema é:

PC não entra em suspensão

então procurar apenas:

powercfg /lastwake

pode desviar a investigação.

Esse comando ganha importância quando:

PC suspendeu
↓
depois acordou

---

Dispositivos capazes de acordar o computador

Execute:

powercfg /devicequery wake_armed

Ele pode listar dispositivos atualmente configurados com capacidade de despertar o sistema.

Exemplos possíveis incluem:

• placa de rede;
• teclado;
• mouse;
• controladores;
• outros dispositivos compatíveis.

---

wake_armed não significa “este dispositivo acordou o PC”

Essa distinção é fundamental.

Imagine que:

powercfg /devicequery wake_armed

liste:

Mouse
Teclado
Adaptador de rede

Isso não prova que a placa de rede acordou o computador.

Significa que esses dispositivos estão configurados de forma que podem ter capacidade de despertar o sistema.

Para investigar o evento ocorrido, precisamos correlacionar outras evidências.

---

Capacidade não é causalidade

Guarde esta regra:

pode acordar
≠
acordou

Isso evita um dos erros mais comuns nesse diagnóstico.

---

Timers também podem despertar o computador

Outro comando:

powercfg /waketimers

pode ajudar a identificar timers de despertar ativos.

Isso é especialmente interessante quando o computador:

suspende normalmente
↓
acorda em determinado horário

---

Um horário recorrente é uma pista excelente

Imagine:

PC acorda quase sempre às 03:00

Isso é muito diferente de:

PC acorda quando mexo o mouse

O primeiro caso faz timers e tarefas ganharem prioridade.

O segundo faz dispositivos ganharem prioridade.

---

Cronometre e documente

Registre:

Horário em que pediu suspensão:
22:15

Entrou em suspensão?
Sim

Horário em que acordou:
03:02

Agora temos um evento real para investigar.

---

Não altere cinco coisas ao mesmo tempo

Se você:

desativa mouse
+
desativa placa de rede
+
altera plano
+
desativa timers
+
atualiza driver

e o problema desaparece, você não sabe qual mudança resolveu.

Prefira:

uma hipótese
↓
uma alteração
↓
um teste

---

Primeira árvore de diagnóstico

Neste ponto já podemos montar:

PC parece não suspender
↓
confirmar comportamento
↓
qual problema?
├── não entra em suspensão
│   ↓
│   powercfg /requests
│
├── entra e acorda sozinho
│   ↓
│   powercfg /lastwake
│   powercfg /waketimers
│   powercfg /devicequery wake_armed
│
└── comportamento de energia diferente do esperado
    ↓
    powercfg /a
    ↓
    verificar Modern Standby / estados disponíveis

---

Checklist inicial

Antes de alterar qualquer coisa, registre:

[ ] Modelo do comportamento observado
[ ] Tela apenas apagou ou PC suspendeu?
[ ] Horário do teste
[ ] Resultado de powercfg /a
[ ] Esquema ativo
[ ] Resultado de powercfg /requests
[ ] Resultado de powercfg /lastwake
[ ] Dispositivos wake_armed
[ ] Wake timers
[ ] Programa aberto no momento
[ ] Dispositivo conectado recentemente
[ ] Se o problema acontece sempre ou ocasionalmente

Esses dados transformam uma reclamação genérica em diagnóstico.

---

O principal conceito desta primeira parte

Não existe um único comando mágico para todo problema de suspensão.

Cada ferramenta responde uma pergunta:

powercfg /a
→ quais estados de energia estão disponíveis?

powercfg /requests
→ existe alguma solicitação mantendo o sistema ativo?

powercfg /devicequery wake_armed
→ quais dispositivos estão habilitados para despertar?

powercfg /waketimers
→ existem timers de despertar?

powercfg /lastwake
→ o que sabemos sobre o último despertar?

Antes de procurar uma solução, precisamos escolher a pergunta correta.

powercfg /requests: como descobrir qual programa ou driver está bloqueando a suspensão

Na primeira parte, separamos três situações que frequentemente são confundidas:

PC não entra em suspensão

PC entra em suspensão e acorda sozinho

e:

tela apaga, mas Windows continua ativo

Agora vamos nos concentrar principalmente no primeiro caso.

O usuário solicita a suspensão ou espera o tempo configurado, mas alguma atividade parece impedir o sistema de dormir.

A ferramenta central desta etapa será:

powercfg /requests

Ela pode revelar solicitações de energia associadas a processos e drivers.

Mas existe uma diferença enorme entre:

“Existe uma solicitação de energia.”

e:

“Descobri por que essa solicitação existe.”

Nosso objetivo é chegar à segunda resposta.

---

Execute powercfg /requests no momento certo

Abra o Terminal ou Prompt de Comando com privilégios administrativos quando necessário e execute:

powercfg /requests

O momento da execução importa.

Imagine:

19:00 → aplicativo inicia atividade
19:01 → solicitação aparece
19:10 → atividade termina
19:11 → solicitação desaparece

Se você consultar às:

19:15

talvez não encontre nada.

Por isso, tente reproduzir o problema e consultar enquanto ele ocorre.

---

Quais categorias podem aparecer?

Dependendo da versão, configuração e atividade do sistema, o comando pode apresentar categorias como:

DISPLAY
SYSTEM
AWAYMODE
EXECUTION
PERFBOOST
ACTIVELOCKSCREEN

Nem todas necessariamente terão solicitações.

O importante é entender que cada categoria representa um tipo de solicitação.

---

DISPLAY: algo solicita que a tela permaneça ligada

Uma solicitação em:

DISPLAY

indica uma condição relacionada a manter a exibição ativa.

Um exemplo típico é um aplicativo reproduzindo conteúdo.

Conceitualmente:

reprodução
↓
solicitação DISPLAY
↓
Windows evita desligar a tela

Isso não significa necessariamente que o programa esteja com defeito.

Pode ser exatamente o comportamento esperado.

---

Exemplo prático de DISPLAY

Imagine que você esteja assistindo a um vídeo.

O plano de energia diz:

Desligar tela após 5 minutos

Mas seria bastante inconveniente se a tela apagasse durante a reprodução.

O aplicativo pode informar ao Windows que a exibição precisa permanecer ativa.

Quando a reprodução termina, espera-se que essa necessidade deixe de existir.

---

Quando DISPLAY vira uma pista de problema?

Quando:

reprodução terminou
↓
aplicativo aparentemente fechado
↓
DISPLAY continua ativo

Agora vale investigar:

• processo em segundo plano;
• janela escondida;
• componente auxiliar;
• bug;
• mídia ainda aberta.

---

SYSTEM: solicitação para manter o sistema ativo

Uma entrada em:

SYSTEM

é particularmente importante quando investigamos um computador que não entra em suspensão.

Conceitualmente:

processo ou driver
↓
SYSTEM request
↓
sistema deve permanecer disponível

Se encontrarmos um executável conhecido, já temos uma pista.

---

Exemplo conceitual

Imagine:

SYSTEM:
[PROCESS] ProgramaBackup.exe

O primeiro impulso poderia ser:

“O programa de backup está impedindo a suspensão.”

Mas ainda precisamos perguntar:

o backup está acontecendo neste momento?

Se sim, manter o sistema acordado pode ser totalmente legítimo.

---

Atividade legítima versus solicitação presa

Compare:

Caso normal

backup inicia
↓
SYSTEM request aparece
↓
backup termina
↓
request desaparece

Caso suspeito

backup inicia
↓
SYSTEM request aparece
↓
backup termina
↓
request permanece indefinidamente

O segundo caso merece investigação.

---

Não finalize o programa antes de observar o comportamento

Se você encerra imediatamente o processo, perde a oportunidade de descobrir:

• o que ele estava fazendo;
• quando a solicitação começou;
• se desapareceria naturalmente;
• se existe correlação reproduzível.

Primeiro observe.

---

Identifique o processo corretamente

Se /requests apontar para um executável, procure-o no Gerenciador de Tarefas.

Use:

Ctrl + Shift + Esc

Depois consulte a guia Detalhes.

Anote:

Nome
PID
Usuário

---

PowerShell pode complementar

Por exemplo:

Get-Process -Name Programa |
Select-Object Id, ProcessName, StartTime

Se você já conhece o PID:

Get-Process -Id 5840

---

Descubra o caminho do executável

Não investigue apenas:

Programa.exe

Procure o caminho:

C:\Program Files\Empresa\Programa.exe

Isso ajuda a identificar o fabricante e a função.

---

Process Explorer pode ajudar

Com o Process Explorer, você pode verificar:

• caminho;
• command line;
• empresa;
• assinatura;
• processo pai;
• usuário;
• DLLs;
• threads.

Isso é especialmente útil quando o nome do executável é genérico.

---

Exemplo: agent.exe

Imagine que /requests aponte:

agent.exe

Esse nome sozinho é pouco informativo.

Poderia pertencer a vários softwares.

Agora encontramos:

C:\Program Files\EmpresaBackup\agent.exe

e:

Company:
Empresa Backup

O diagnóstico começa a fazer sentido.

---

Verifique a assinatura

No PowerShell:

Get-AuthenticodeSignature "C:\Program Files\EmpresaBackup\agent.exe"

A assinatura ajuda a identificar o editor.

Mas mantenha a mesma regra:

assinado
≠
sem bugs

e:

não assinado
≠
automaticamente malware

---

AWAYMODE: um conceito menos conhecido

Outra categoria que pode aparecer é:

AWAYMODE

Away Mode foi projetado para cenários em que o computador precisa aparentar estar inativo para o usuário, mas continuar realizando determinadas funções.

Isso pode aparecer em situações relacionadas a mídia e outras atividades específicas.

---

Away Mode não é simplesmente suspensão

Conceitualmente:

usuário espera estado de baixo uso
↓
sistema continua realizando atividade

Portanto, se uma solicitação de AWAYMODE aparece, precisamos entender qual componente está pedindo esse comportamento.

---

Não tente eliminar AWAYMODE apenas porque o nome parece estranho

O primeiro passo continua sendo:

quem solicitou?
↓
qual programa?
↓
qual atividade?
↓
é esperado?

Só depois pense em alterar configuração.

---

EXECUTION: atividade que precisa continuar

Outra categoria possível:

EXECUTION

pode estar associada a atividades cuja execução não deveria ser interrompida naquele momento.

Novamente, o contexto é fundamental.

Um processo realizando uma tarefa longa pode ter motivo legítimo para solicitar continuidade.

---

PERFBOOST não significa necessariamente bloqueio clássico de suspensão

Categorias diferentes representam solicitações diferentes.

Não transforme qualquer entrada do /requests em:

“Achei quem impede o PC de dormir.”

Leia a categoria e entenda o que ela representa.

---

ACTIVELOCKSCREEN também depende do contexto

Algumas versões e configurações podem apresentar categorias adicionais.

A regra permanece:

não interprete apenas pelo nome do executável; interprete categoria + processo + atividade + momento.

---

Drivers podem aparecer em powercfg /requests

Esse é um dos casos mais interessantes.

Imagine uma saída relacionada a:

[DRIVER]

O usuário pode pensar:

“Então meu driver está com defeito.”

Não necessariamente.

Um driver pode estar atendendo a uma atividade legítima solicitada por algum aplicativo.

---

Áudio é um caso clássico para investigar

Podemos ter uma cadeia conceitual:

Aplicativo
↓
sessão de áudio
↓
driver
↓
solicitação SYSTEM

Você vê o driver no /requests, mas a causa original pode ser um programa utilizando áudio.

---

Como investigar áudio?

Primeiro verifique se existe alguma atividade de áudio.

Pode ser:

• navegador;
• player;
• chamada;
• aplicativo de comunicação;
• software de gravação;
• processo em segundo plano.

Observe o mixer de volume e os processos ativos.

---

Navegador fechado visualmente pode continuar ativo

Alguns navegadores podem manter processos em segundo plano dependendo das configurações e extensões.

Então:

fechei a janela

não significa necessariamente:

todos os processos terminaram

Confira no Gerenciador de Tarefas.

---

Teste simples

Antes:

powercfg /requests

Anote o resultado.

Feche corretamente o aplicativo suspeito.

Espere alguns segundos.

Execute novamente:

powercfg /requests

Compare.

---

Teste A/B é melhor que “pareceu resolver”

Idealmente:

programa aberto
→ request aparece

programa fechado
→ request desaparece

programa aberto novamente
→ request reaparece

Essa repetibilidade fortalece muito a conclusão.

---

USB também pode entrar na investigação

Dispositivos USB e seus drivers podem participar de problemas de energia.

Exemplos:

• interfaces de áudio;
• docks;
• adaptadores;
• dispositivos de captura;
• periféricos especializados.

Mas não comece desconectando tudo de forma aleatória.

---

Teste periféricos de forma organizada

Se existe suspeita de USB:

1. Registre /requests.
2. Desconecte um dispositivo não essencial.
3. Aguarde.
4. Execute /requests novamente.
5. Teste suspensão.

Repita um dispositivo por vez.

---

Por que um por vez?

Imagine que você desconecte:

webcam
+
headset
+
HD externo
+
dock
+
adaptador USB

e o problema desapareça.

Você sabe apenas que:

alguma mudança resolveu

mas não sabe qual.

---

Bluetooth também merece atenção em alguns casos

Periféricos Bluetooth podem interagir com políticas de energia e despertar.

Mas lembre-se de separar:

impedir entrada em suspensão

de:

acordar depois da suspensão

Se o PC entra em suspensão e acorda, a investigação muda para wake sources.

---

Rede é outro exemplo que gera confusão

A placa de rede pode estar configurada para acordar o computador.

Isso é relevante para:

PC suspende
↓
rede provoca wake

Mas isso não é necessariamente a causa de:

PC nunca entra em suspensão

Não misture os dois diagnósticos.

---

Wake-on-LAN pertence principalmente ao segundo cenário

Se a placa recebe um evento de wake depois da suspensão, investigamos recursos de despertar.

Isso envolve comandos como:

powercfg /devicequery wake_armed

e:

powercfg /lastwake

Não use a configuração de Wake-on-LAN como explicação automática para uma solicitação SYSTEM.

---

E se powercfg /requests apontar para um compartilhamento?

Em determinadas situações, atividade de rede ou arquivos compartilhados pode manter solicitações relacionadas ao sistema.

Antes de desativar compartilhamento, descubra:

• existe transferência?
• algum computador está acessando?
• existe sessão aberta?
• backup está utilizando rede?

---

Veja conexões e atividade antes de alterar

Se a suspeita envolve compartilhamento SMB, podemos complementar o diagnóstico com ferramentas específicas do Windows.

O objetivo continua sendo correlacionar a solicitação com atividade real.

---

O que é powercfg /requestsoverride?

Agora chegamos a um comando que exige cuidado:

powercfg /requestsoverride

Ele pode ser utilizado para configurar substituições relacionadas a determinadas solicitações de energia.

Em outras palavras, você pode instruir o sistema a ignorar uma solicitação específica em determinado contexto.

Isso parece uma solução perfeita.

Mas frequentemente não é a primeira solução que deveríamos aplicar.

---

Por que /requestsoverride pode ser perigoso como solução automática?

Imagine:

ProgramaBackup.exe
↓
faz backup
↓
solicita SYSTEM

Você cria um override para ignorar essa solicitação.

Depois:

backup está executando
↓
Windows entra em suspensão

Dependendo da aplicação e atividade, você pode interromper justamente algo que precisava continuar.

---

Override não corrige necessariamente a causa

Imagine que um driver deveria remover uma solicitação ao terminar uma operação, mas não remove.

Você pode:

ignorar request

e mascarar o sintoma.

Mas o comportamento anormal do driver continua existindo.

---

Primeiro descubra por que a solicitação existe

A sequência correta é:

powercfg /requests
↓
identificar origem
↓
entender atividade
↓
corrigir programa/driver/configuração
↓
considerar override somente se fizer sentido

---

Consulte overrides existentes antes de criar novos

Execute:

powercfg /requestsoverride

sem parâmetros adicionais para verificar configurações existentes.

Isso é importante.

Talvez alguém já tenha criado overrides anteriormente.

---

Overrides antigos podem complicar o diagnóstico

Imagine um computador que já passou por vários “tutoriais de otimização”.

Pode existir uma configuração criada meses atrás.

Agora:

comportamento atual

é influenciado por:

override antigo

Por isso, documente o estado.

---

Não copie comandos de override sem adaptar

Você pode encontrar exemplos na Internet usando nomes específicos de drivers ou processos.

Não copie cegamente.

O identificador precisa corresponder ao componente real do seu computador e a decisão precisa fazer sentido para aquele caso.

---

Quando considerar requestsoverride?

Somente depois de responder perguntas como:

1. Qual componente está fazendo a solicitação?
2. Por que ele está fazendo?
3. A atividade precisa continuar?
4. Existe atualização ou correção?
5. Existe configuração dentro do próprio programa?
6. Ignorar a solicitação pode interromper alguma operação?
7. O problema é reproduzível?

Sem essas respostas, o override vira tentativa.

---

Atualizar o programa pode ser melhor

Se um aplicativo mantém uma solicitação indevidamente por bug, uma versão corrigida pode resolver o comportamento.

Verifique a versão instalada antes de alterar o gerenciamento de energia do Windows.

---

Atualizar driver também pode fazer sentido

Quando a evidência aponta claramente para um driver e existe atualização apropriada do fabricante, atualizar pode ser uma etapa válida.

Mas não aplique:

atualize todos os drivers

como diagnóstico.

Atualização indiscriminada dificulta saber o que mudou.

---

Driver mais novo nem sempre significa driver melhor para aquele equipamento

Especialmente em notebooks, determinados componentes podem depender de pacotes e integrações fornecidos pelo fabricante.

Portanto, considere:

• Windows Update;
• fabricante do computador;
• fabricante do componente;
• versão atual.

---

BIOS/UEFI pode participar de problemas de energia

Gerenciamento de energia envolve uma interação entre:

Windows
+
drivers
+
firmware
+
hardware

Por isso, problemas persistentes podem exigir investigação de BIOS/UEFI.

Mas novamente:

não atualize BIOS como primeira tentativa sem evidências e sem seguir o procedimento seguro do fabricante.

---

Modern Standby muda parte da investigação

Se:

powercfg /a

indica Modern Standby, o comportamento de energia pode diferir do S3 tradicional.

Nesse caso, ferramentas específicas de relatório ganham importância.

Uma delas é:

powercfg /sleepstudy

Vamos aprofundá-la na próxima parte.

---

SleepStudy não é substituto de /requests

Eles respondem perguntas diferentes.

/requests
→ quem está solicitando energia agora?

SleepStudy
→ o que aconteceu durante sessões de Modern Standby?

Essa distinção evita interpretações erradas.

---

system sleep diagnostics também pode ajudar

Outra opção é:

powercfg /systemsleepdiagnostics

Ela pode gerar informações relacionadas às transições de suspensão do sistema, dependendo do suporte e contexto.

Novamente, isso não substitui a investigação em tempo real com /requests.

---

Não ignore o Visualizador de Eventos

Problemas de energia também podem deixar pistas nos logs.

Abra:

eventvwr.msc

Podemos investigar eventos relacionados a:

• Kernel-Power;
• Power-Troubleshooter;
• transições de energia;
• drivers;
• falhas próximas ao horário.

---

Horário é fundamental

Se você pediu suspensão às:

23:12:30

registre isso.

Depois procure eventos próximos.

Sem horário, o Event Viewer pode parecer apenas uma coleção enorme de mensagens.

---

Faça testes controlados

Um excelente teste:

1. Reinicie o Windows.
2. Não abra programas extras.
3. Aguarde estabilizar.
4. Execute powercfg /requests.
5. Teste suspensão.

Depois:

6. Abra o aplicativo suspeito.
7. Execute /requests novamente.
8. Teste suspensão.

Compare os dois estados.

---

Inicialização limpa pode ser útil posteriormente

Se o problema desaparece quando programas e serviços de terceiros não são carregados, isso ajuda a reduzir o universo de causas.

Mas não comece desativando tudo.

Primeiro tente identificar a solicitação diretamente.

---

Cenário prático 1 — navegador

Situação:

PC não suspende

powercfg /requests aponta atividade relacionada a um componente usado pelo navegador.

Você fecha todas as janelas.

A solicitação continua.

Gerenciador de Tarefas mostra processos do navegador em segundo plano.

Depois de encerrar corretamente a execução em segundo plano:

request desaparece

Agora existe uma correlação.

---

Cenário prático 2 — aplicativo de mídia

Durante reprodução:

DISPLAY
+
SYSTEM

aparecem.

Ao parar a reprodução:

requests desaparecem

Isso provavelmente é comportamento esperado.

Não existe problema para corrigir.

---

Cenário prático 3 — driver de áudio

Nenhuma mídia parece estar sendo reproduzida.

Mesmo assim /requests aponta atividade relacionada a áudio.

Agora investigamos:

Mixer
↓
aplicativos
↓
serviços de comunicação
↓
processos em segundo plano
↓
driver

antes de desativar o dispositivo.

---

Cenário prático 4 — backup

Backup ativo:

SYSTEM request

Backup termina:

request desaparece

Normal.

Mas se permanece por horas após o backup:

investigar software

---

Cenário prático 5 — dispositivo USB

Com dispositivo conectado:

request presente

Desconectado:

request desaparece

Reconectado:

request retorna

Agora temos um teste A/B forte.

O próximo passo é identificar:

• dispositivo;
• driver;
• software associado.

---

Cenário prático 6 — /requests vazio, mas PC continua ligado

Não conclua que powercfg “não funciona”.

Pergunte:

o PC tentou suspender?

Verifique:

• tempo configurado;
• esquema ativo;
• estados suportados;
• Modern Standby;
• eventos;
• se ele entrou e acordou imediatamente.

Pode ser outro tipo de problema.

---

Um wake imediato parece uma falha de entrada em suspensão

Imagine:

23:00:00 → PC suspende
23:00:01 → dispositivo acorda PC

Para o usuário:

“Ele não suspendeu.”

Mas tecnicamente:

suspendeu
+
acordou em 1 segundo

Isso muda totalmente o diagnóstico.

---

Como perceber essa diferença?

Correlacione:

powercfg /lastwake

com:

powercfg /devicequery wake_armed

e os eventos do Windows.

Na próxima parte, vamos aprofundar exatamente isso.

---

Checklist de investigação com /requests

[ ] Executei /requests durante o problema
[ ] Registrei a categoria
[ ] Identifiquei processo ou driver
[ ] Descobri o caminho do executável
[ ] Verifiquei fabricante
[ ] Verifiquei assinatura
[ ] Identifiquei atividade associada
[ ] Fechei corretamente o programa
[ ] Executei /requests novamente
[ ] Fiz teste A/B
[ ] Testei periféricos um por vez
[ ] Verifiquei esquema ativo
[ ] Consultei estados disponíveis
[ ] Verifiquei overrides existentes
[ ] Não criei override sem entender a causa

---

Árvore de diagnóstico atualizada

PC não suspende
↓
powercfg /requests
↓
há request?
├── SIM
│   ↓
│   processo ou driver?
│   ↓
│   identificar atividade
│   ↓
│   teste A/B
│   ↓
│   corrigir origem
│
└── NÃO
    ↓
    verificar se realmente tentou suspender
    ↓
    verificar estados disponíveis
    ↓
    verificar Modern Standby
    ↓
    verificar se suspendeu e acordou imediatamente

Se o computador efetivamente entra em suspensão e volta:

mudar de trilha
↓
lastwake
↓
wake_armed
↓
waketimers
↓
Event Viewer

---

O principal aprendizado desta parte

powercfg /requests não é uma lista de “culpados”.

Ele mostra solicitações de energia que precisam ser interpretadas.

A análise correta é:

request
↓
categoria
↓
processo/driver
↓
atividade
↓
teste
↓
causa

Só depois disso devemos pensar em:

• configuração;
• atualização;
• correção;
• override.

Usar:

powercfg /requestsoverride

sem entender a solicitação pode apenas esconder o problema e permitir que o computador suspenda durante uma atividade que precisava permanecer ativa.

O PC suspende e acorda sozinho: lastwake, wake timers, dispositivos e SleepStudy

Até agora tratamos principalmente do cenário em que o Windows 11 não consegue entrar em suspensão porque algum programa, driver ou componente mantém uma solicitação ativa.

Agora vamos mudar completamente de trilha.

O computador entra em suspensão.

Depois:

alguns segundos
↓
alguns minutos
↓
algumas horas

ele acorda sozinho.

Esse comportamento exige outro tipo de investigação.

A pergunta agora deixa de ser:

“Quem está impedindo a suspensão?”

e passa a ser:

“Quem acordou o computador?”

As principais ferramentas desta etapa serão:

powercfg /lastwake
powercfg /devicequery wake_armed
powercfg /waketimers

Além delas, vamos usar o Visualizador de Eventos e, em equipamentos com Modern Standby, o SleepStudy.

---

Comece confirmando que o PC realmente suspendeu

Antes de investigar wake sources, precisamos ter certeza de que houve uma transição real para suspensão.

Imagine:

23:10:00 → usuário clica em Suspender
23:10:02 → tela apaga
23:10:04 → sistema continua ativo

Isso pode não ser um wake.

Agora compare:

23:10:00 → suspensão
23:10:05 → sistema entra em estado de baixo consumo
23:15:32 → sistema retorna

Aqui existe um evento de despertar para investigar.

---

powercfg /lastwake

Depois que o computador acordar, execute:

powercfg /lastwake

Esse comando tenta mostrar informações relacionadas ao último evento de despertar registrado.

Ele pode fornecer pistas sobre:

• dispositivo;
• fonte de wake;
• evento relacionado;
• informação do último despertar.

A qualidade do resultado pode variar conforme hardware, firmware e tipo de suspensão.

---

/lastwake vazio não significa que nada acordou o PC

Às vezes o comando pode não fornecer uma identificação clara.

Isso não significa automaticamente:

“não houve wake”

Pode ser necessário combinar:

/lastwake
+
Event Viewer
+
wake_armed
+
waketimers

Nenhuma dessas ferramentas deve ser tratada como prova isolada em todos os casos.

---

powercfg /devicequery wake_armed

Execute:

powercfg /devicequery wake_armed

Esse comando lista dispositivos atualmente configurados com permissão para acordar o computador.

Exemplos comuns podem incluir:

• mouse;
• teclado;
• adaptador Ethernet;
• adaptador Wi-Fi;
• controladores USB;
• outros dispositivos.

Mas existe uma regra importante:

wake_armed
≠
culpado pelo último wake

Ele mostra capacidade configurada.

Não causalidade.

---

Exemplo

Suponha que a saída mostre:

Mouse compatível com HID
Teclado compatível com HID
Intel Ethernet Controller

Isso significa que esses dispositivos podem ter permissão para despertar o sistema.

Agora:

powercfg /lastwake

pode apontar para a placa de rede.

Nesse caso, as duas evidências se complementam.

---

Mouse acordando o computador

Um mouse pode despertar o PC por:

• movimento;
• vibração da mesa;
• sensor sensível;
• pequeno deslocamento;
• conexão USB.

Isso é especialmente comum em mouses muito sensíveis.

---

Como testar o mouse

No Gerenciador de Dispositivos, localize o dispositivo correspondente.

Quando existir a opção apropriada, verifique configurações de gerenciamento de energia relacionadas a:

Permitir que este dispositivo acorde o computador

Faça o teste em apenas um dispositivo por vez.

---

Não desative o wake do teclado e do mouse ao mesmo tempo sem pensar

Se você impedir todos os dispositivos de entrada de acordar o computador, pode ficar dependente do botão físico de energia para retornar.

Isso pode ser perfeitamente aceitável, mas deve ser uma decisão consciente.

---

Placa de rede é uma das principais suspeitas

Adaptadores de rede frequentemente têm recursos relacionados a wake.

Isso pode incluir:

• Wake-on-LAN;
• Magic Packet;
• Pattern Match;
• recursos específicos do fabricante.

Se o PC acorda sem interação humana, a placa de rede merece investigação.

---

Wake-on-LAN não significa qualquer pacote de rede

Dependendo da configuração do adaptador, o wake pode estar restrito a:

Magic Packet

ou pode existir suporte a outros padrões/eventos.

Verifique as propriedades avançadas do driver e as opções de gerenciamento de energia.

---

Um teste útil com a placa de rede

Se /lastwake aponta repetidamente para o adaptador de rede:

1. registre a configuração atual;
2. verifique as opções de wake;
3. faça uma alteração controlada;
4. suspenda;
5. aguarde;
6. verifique se o comportamento muda.

Evite alterar várias opções simultaneamente.

---

Wi-Fi também pode participar

Em notebooks, adaptadores sem fio podem ter comportamentos relacionados a energia e conectividade durante estados modernos de espera.

Por isso, não pense apenas em Ethernet.

---

powercfg /waketimers

Agora execute:

powercfg /waketimers

Esse comando procura timers ativos capazes de despertar o sistema.

Ele é especialmente útil quando o computador acorda:

sempre perto do mesmo horário

---

Exemplo clássico

Você suspende o computador às:

23:00

Ele acorda quase todos os dias por volta de:

03:00

Isso sugere investigar:

wake timer
+
tarefa agendada
+
manutenção

em vez de culpar imediatamente mouse ou rede.

---

Timers podem ser criados por tarefas

Uma tarefa agendada pode conter uma opção semelhante a:

Ativar o computador para executar esta tarefa

Quando habilitada, ela pode contribuir para um wake programado.

Abra:

taskschd.msc

e examine tarefas compatíveis com o horário observado.

---

Não procure apenas pelo nome

Assim como em outros diagnósticos, o nome da tarefa pode ser genérico.

Verifique:

• gatilhos;
• condições;
• ações;
• histórico;
• horário da última execução.

---

Correlacione o horário

Imagine:

03:01:58 → computador acorda
03:02:00 → tarefa inicia

Essa proximidade é relevante.

Agora compare com:

02:45 → tarefa executou
03:02 → PC acordou

A correlação é bem mais fraca.

---

Event Viewer: procure Power-Troubleshooter

Abra:

eventvwr.msc

Procure eventos relacionados a energia e retomada.

Uma fonte importante é:

Power-Troubleshooter

Esses eventos podem conter informação relacionada ao momento do despertar e à fonte identificada.

---

Kernel-Power também fornece contexto

Eventos de:

Kernel-Power

podem ajudar a entender transições de energia.

Mas não interprete todo evento Kernel-Power como falha.

Esse provedor registra diversos eventos ligados a estados de energia.

---

Monte uma linha do tempo

Exemplo:

22:30:00 → usuário suspende
22:30:05 → sistema entra em suspensão
03:02:11 → wake
03:02:12 → Power-Troubleshooter
03:02:15 → tarefa Maintenance inicia

Isso é muito mais útil do que simplesmente:

“Meu PC ligou sozinho de madrugada.”

---

Horários recorrentes são extremamente valiosos

Se o problema acontece:

sempre entre 02:55 e 03:05

há boa chance de existir um gatilho programado.

Se acontece:

em horários aleatórios

dispositivos e eventos externos ganham mais peso.

---

Diferencie wake por dispositivo de wake por timer

Fluxo simplificado:

PC acordou
↓
/lastwake
↓
há dispositivo identificado?
├── SIM
│   ↓
│   verificar wake_armed e configuração
│
└── NÃO
    ↓
    /waketimers
    ↓
    verificar tarefa/evento

Isso não cobre todos os casos, mas organiza a investigação.

---

Wake source desconhecida

Às vezes o Event Viewer ou /lastwake pode não apontar claramente a origem.

Nesse caso, registre:

• horário;
• duração da suspensão;
• dispositivos wake_armed;
• wake timers;
• tarefas próximas;
• conectividade;
• periféricos.

Depois repita o teste.

Um único evento inconclusivo não significa que o problema é insolúvel.

---

USB pode causar wakes inesperados

Dispositivos USB podem gerar eventos de despertar.

Exemplos:

• mouse;
• teclado;
• dock;
• receptor sem fio;
• controle;
• interface de áudio.

Se houver suspeita:

desconecte um periférico não essencial por vez

e repita o teste.

---

Docking station merece atenção

Notebooks conectados a docks podem ter vários dispositivos representados por uma única conexão física.

Isso pode incluir:

• Ethernet;
• USB;
• áudio;
• vídeo;
• hubs.

Se o problema acontece apenas com o notebook conectado à dock, isso é uma pista importante.

---

Fechar a tampa não é exatamente o mesmo teste que clicar em Suspender

A ação da tampa pode estar configurada para:

• não fazer nada;
• suspender;
• hibernar;
• outra ação.

Portanto, se o problema só acontece ao fechar a tampa, confira a configuração.

---

Modern Standby muda bastante o comportamento

Em PCs com Modern Standby, o sistema pode manter determinadas atividades em baixo consumo.

Isso significa que o usuário pode observar comportamentos diferentes do S3 clássico.

Para descobrir o suporte:

powercfg /a

---

SleepStudy

Em sistemas compatíveis, execute:

powercfg /sleepstudy

O comando gera um relatório que pode ajudar a analisar sessões de Modern Standby.

---

O que o SleepStudy pode mostrar?

Ele pode ajudar a entender aspectos como:

• duração de sessões;
• atividade durante o período;
• consumo;
• componentes mais ativos;
• transições.

Isso é particularmente útil quando o problema é:

“o notebook fica quente na mochila”

ou:

“a bateria cai muito enquanto deveria estar dormindo”

Mesmo quando o usuário chama isso genericamente de “não suspender”.

---

Modern Standby pode parecer que o PC nunca dorme

Isso acontece porque o comportamento físico pode ser menos óbvio.

O sistema pode permanecer em um modo de baixo consumo com determinadas atividades permitidas.

Por isso, em notebooks modernos:

LED aceso

ou:

rede ativa

não deve ser interpretado isoladamente.

---

SleepStudy e wake diagnostics não são a mesma coisa

/lastwake
→ último despertar

/waketimers
→ timers capazes de despertar

/sleepstudy
→ análise de sessões Modern Standby

Cada comando responde outra pergunta.

---

system sleep diagnostics

Também podemos gerar:

powercfg /systemsleepdiagnostics

Esse relatório pode fornecer informações sobre transições de suspensão e atividade relacionada ao sistema.

Ele pode ajudar em diagnósticos em que o comportamento histórico importa mais que o estado atual.

---

powercfg /energy

Outra ferramenta complementar é:

powercfg /energy

Ela gera um relatório de diagnóstico de eficiência energética.

Pode apontar:

• configurações;
• dispositivos;
• solicitações;
• problemas relacionados a energia.

Mas não trate cada aviso como causa direta do sintoma.

O relatório costuma conter observações que precisam de interpretação.

---

Gere relatórios em uma pasta fácil de localizar

Quando apropriado, você pode direcionar a saída para um arquivo.

Exemplo:

powercfg /energy /output C:\Temp\energy-report.html

Certifique-se de que a pasta exista.

---

Não publique SleepStudy ou energy report sem revisar

Relatórios podem conter:

• nomes do computador;
• informações de hardware;
• caminhos;
• detalhes do sistema.

Se você pretende compartilhar o arquivo, revise antes.

---

Tarefas de manutenção

O Windows e softwares instalados podem criar tarefas relacionadas a:

• atualização;
• manutenção;
• verificação;
• backup.

Algumas podem ter capacidade de acordar o PC.

Isso não significa que toda tarefa programada seja problemática.

---

Quando o wake é normal?

Exemplo:

backup agendado
↓
wake permitido
↓
backup executa
↓
PC volta a suspender

Se isso foi configurado conscientemente, não há necessariamente problema.

O problema é quando o wake:

• é inesperado;
• ocorre repetidamente;
• impede economia de energia;
• aquece o notebook;
• consome bateria.

---

Wake para Windows Update

Atualizações e manutenção também podem participar de cenários de wake.

Se o horário coincide com atividades de atualização, investigue os eventos e tarefas relacionadas.

Mas não conclua isso apenas porque o Windows Update existe.

---

Desabilitar todos os wake timers pode resolver, mas não diagnostica

Nas opções avançadas de energia, o usuário pode encontrar configurações relacionadas a wake timers.

Desativá-los globalmente pode impedir certos despertares.

Mas isso também pode impedir tarefas legítimas.

Primeiro descubra qual timer existe.

---

Teste controlado com wake timers

Se:

powercfg /waketimers

mostra uma tarefa específica, investigue essa tarefa.

Se ela não é necessária para acordar o PC, ajuste a configuração dela.

Isso é melhor do que desativar todos os timers indiscriminadamente.

---

O botão de energia também pode gerar confusão

Dependendo da configuração, pressionar o botão pode:

• desligar;
• suspender;
• hibernar.

Confirme a ação configurada antes de comparar resultados.

---

Hibernação é um ótimo teste comparativo

Se o computador acorda sozinho durante suspensão, você pode observar se o mesmo ocorre ao usar hibernação.

Os mecanismos de wake podem se comportar de forma diferente dependendo do estado.

Isso ajuda a separar problema de suspensão específica de algo mais geral.

---

Atenção ao Fast Startup

Inicialização Rápida está mais relacionada ao desligamento e inicialização do que à suspensão clássica.

Desativá-la como solução universal para qualquer problema de sono pode desviar a investigação.

---

Cenário prático 1 — mouse

Resultado:

powercfg /lastwake

indica dispositivo de entrada.

wake_armed mostra o mouse.

Depois de impedir temporariamente o wake pelo mouse:

PC permanece suspenso

Reativando:

wake inesperado volta

Temos uma confirmação forte.

---

Cenário prático 2 — Ethernet

O computador acorda quando há atividade na rede.

/lastwake aponta o adaptador.

O driver permite múltiplos padrões de wake.

Depois de configurar apenas Magic Packet, o problema desaparece.

Nesse caso, o diagnóstico é muito mais específico que simplesmente “desative Wake-on-LAN”.

---

Cenário prático 3 — tarefa às 03:00

/waketimers mostra um timer.

O Task Scheduler contém tarefa com:

Wake the computer to run this task

e horário correspondente.

Depois de ajustar a condição:

wake deixa de ocorrer

Causa identificada.

---

Cenário prático 4 — notebook descarrega dormindo

O usuário diz:

“Ele não suspende.”

Mas:

powercfg /a

mostra Modern Standby.

O SleepStudy revela atividade significativa durante sessões de espera.

Agora o problema é:

alto consumo durante Modern Standby

e não simplesmente ausência de suspensão.

---

Cenário prático 5 — PC acorda imediatamente

Fluxo:

Suspender
↓
1 segundo
↓
PC volta

Isso pode parecer:

“não suspende”

mas /lastwake aponta um dispositivo.

A investigação correta é wake imediato.

---

Cenário prático 6 — nenhuma fonte clara

/lastwake não ajuda.

/waketimers vazio.

Vários dispositivos wake_armed.

Faça testes um a um começando pelos dispositivos mais plausíveis.

Mantenha uma tabela:

Teste	Alteração	Resultado
1	mouse sem wake	acordou
2	rede sem wake	permaneceu suspenso
3	rede reativada	acordou

Esse método reduz muito a incerteza.

---

Quando olhar BIOS/UEFI?

Se o Windows não explica totalmente o comportamento, o firmware pode oferecer configurações de wake como:

• Wake on LAN;
• Wake on PCIe;
• USB wake;
• RTC alarm;
• wake por teclado.

Os nomes variam muito entre fabricantes.

---

RTC alarm

Alguns firmwares permitem programar um horário para ligar ou despertar o computador.

Se o PC acorda sempre no mesmo horário e o Windows não mostra timer correspondente, vale verificar o firmware.

---

Não altere todas as opções da BIOS

Registre primeiro:

• valor original;
• opção alterada;
• resultado.

BIOS/UEFI também exige cuidado maior que uma simples configuração do Windows.

---

Atualização de firmware pode corrigir energia

Fabricantes podem publicar atualizações que corrigem:

• Modern Standby;
• ACPI;
• USB wake;
• consumo em espera;
• compatibilidade.

Mas firmware deve ser atualizado seguindo exatamente as instruções do fabricante e somente quando fizer sentido para o diagnóstico.

---

ACPI participa da conversa

O Windows depende de informações fornecidas pelo firmware através de mecanismos como ACPI para gerenciamento de energia.

Isso explica por que dois computadores com o mesmo Windows 11 podem ter comportamentos diferentes.

---

Não existe configuração universal

Um desktop montado:

S3 disponível

pode se comportar de uma forma.

Um notebook moderno:

Modern Standby

pode se comportar de outra.

Por isso, sempre comece com:

powercfg /a

---

Árvore completa para wake inesperado

PC suspende e acorda
↓
registrar horário
↓
powercfg /lastwake
↓
fonte clara?
├── dispositivo
│   ↓
│   powercfg /devicequery wake_armed
│   ↓
│   testar configuração
│
├── timer/tarefa
│   ↓
│   powercfg /waketimers
│   ↓
│   taskschd.msc
│
└── inconclusivo
    ↓
    Event Viewer
    ↓
    Power-Troubleshooter
    ↓
    SleepStudy / sleep diagnostics
    ↓
    firmware e testes A/B

---

Checklist da Parte 3

[ ] Confirmei que o PC realmente entrou em suspensão
[ ] Registrei o horário
[ ] Executei powercfg /lastwake
[ ] Executei powercfg /devicequery wake_armed
[ ] Executei powercfg /waketimers
[ ] Verifiquei Power-Troubleshooter
[ ] Verifiquei Kernel-Power
[ ] Correlacionei horários
[ ] Verifiquei tarefas agendadas
[ ] Testei dispositivos um por vez
[ ] Verifiquei placa de rede
[ ] Verifiquei mouse e teclado
[ ] Considerei USB/dock
[ ] Consultei powercfg /a
[ ] Identifiquei se existe Modern Standby
[ ] Gereei SleepStudy quando aplicável
[ ] Evitei alterações em massa

---

A regra mais importante desta parte

Quando o PC acorda sozinho:

“pode acordar”

não é igual a:

“foi quem acordou”

Um dispositivo listado em:

powercfg /devicequery wake_armed

é apenas um candidato.

Uma tarefa existente é apenas um candidato.

Um timer é uma pista.

O melhor diagnóstico vem da combinação:

horário
+
lastwake
+
wake timer
+
evento
+
teste A/B

Agora que já separamos os dois grandes problemas — não conseguir entrar em suspensão e entrar em suspensão, mas acordar sozinho — podemos organizar tudo em uma sequência lógica de diagnóstico.

O objetivo é sair de:

“Meu PC não dorme.”

para algo tecnicamente específico, como:

“O Windows 11 entra em suspensão, mas acorda após alguns segundos porque o adaptador de rede está habilitado para wake e aparece como fonte do último despertar.”

ou:

“O sistema não entra em suspensão porque um processo mantém uma solicitação SYSTEM ativa em powercfg /requests.”

Essa diferença muda completamente a forma de corrigir o problema.

---

Procedimento completo para diagnosticar problemas de suspensão no Windows 11

1. Defina qual é o sintoma real

Antes de qualquer comando, responda:

O PC:
A) não entra em suspensão?
B) entra em suspensão e acorda sozinho?
C) apenas apaga a tela?
D) usa Modern Standby e parece permanecer parcialmente ativo?

Sem essa definição, é fácil usar o comando errado.

---

2. Descubra quais estados de energia o computador suporta

Execute:

powercfg /a

Registre o resultado.

Isso ajuda a entender se o computador trabalha com:

S3
Modern Standby
hibernação
outros estados disponíveis

Não presuma que todos os PCs com Windows 11 usam a mesma arquitetura.

---

3. Verifique o esquema de energia ativo

Execute:

powercfg /getactivescheme

Se quiser listar os esquemas disponíveis:

powercfg /list

ou:

powercfg /l

Anote qual está ativo antes de fazer mudanças.

---

4. Confirme os tempos configurados para tela e suspensão

Verifique nas configurações de energia do Windows:

Desligar tela após:
Suspender após:

Não confunda:

tela desligada

com:

sistema suspenso

---

Se o PC não entra em suspensão

5. Execute powercfg /requests

Use:

powercfg /requests

Faça isso enquanto o problema está acontecendo.

Observe categorias como:

DISPLAY
SYSTEM
AWAYMODE
EXECUTION
PERFBOOST

dependendo do que estiver disponível no sistema.

---

6. Identifique a origem da solicitação

Se aparecer um processo, registre:

nome
caminho
PID
fabricante
atividade atual

Se aparecer um driver, descubra qual dispositivo ou software está relacionado.

---

7. Não conclua que a solicitação é um erro

Pergunte:

o programa está fazendo algo que exige ficar acordado?

Por exemplo:

• reprodução de mídia;
• backup;
• gravação;
• tarefa longa;
• comunicação;
• atividade de hardware.

Se sim, a solicitação pode ser legítima.

---

8. Faça teste A/B

Exemplo:

programa aberto
→ SYSTEM request aparece

programa fechado corretamente
→ request desaparece

programa aberto novamente
→ request retorna

Esse comportamento reproduzível fortalece a hipótese.

---

9. Confira se o programa continua em segundo plano

Fechar uma janela não necessariamente encerra o processo.

Abra:

Ctrl + Shift + Esc

e verifique os processos.

---

10. Identifique o executável com mais detalhes

Use Process Explorer, propriedades do arquivo ou PowerShell.

Exemplo:

Get-AuthenticodeSignature "C:\Caminho\Programa.exe"

e:

(Get-Item "C:\Caminho\Programa.exe").VersionInfo

Registre fabricante e versão.

---

11. Investigue atividade de áudio

Se /requests indicar algo ligado a áudio, veja:

• navegador;
• player;
• chamada;
• software de gravação;
• aplicativos em segundo plano.

Não desative o driver de áudio como primeira tentativa.

---

12. Investigue dispositivos USB de forma controlada

Se houver suspeita:

desconecte um periférico
↓
execute /requests
↓
teste suspensão

Faça um por vez.

---

13. Verifique overrides existentes

Execute:

powercfg /requestsoverride

Isso mostra overrides já configurados.

Talvez o PC tenha alterações antigas feitas por outro usuário ou por algum tutorial anterior.

---

14. Não crie override automaticamente

Evite usar requestsoverride apenas para “fazer o PC dormir”.

Primeiro descubra:

quem solicita
↓
por que solicita
↓
se a atividade pode ser interrompida

---

15. Atualize o programa quando houver evidência

Se um aplicativo claramente mantém uma solicitação indevida e existe versão corrigida, atualizar pode fazer sentido.

---

16. Atualize driver somente quando houver relação clara

Evite:

atualizar todos os drivers

sem saber qual componente está relacionado.

Isso dificulta o diagnóstico.

---

Se o PC entra em suspensão e acorda sozinho

17. Execute powercfg /lastwake

Depois do wake:

powercfg /lastwake

Registre a informação apresentada.

---

18. Liste os dispositivos habilitados para despertar

Execute:

powercfg /devicequery wake_armed

Lembre:

wake_armed
≠
culpado confirmado

É apenas uma lista de candidatos habilitados.

---

19. Procure wake timers

Execute:

powercfg /waketimers

Isso é especialmente importante se o PC acorda em horário recorrente.

---

20. Registre o horário exato do despertar

Exemplo:

Suspensão: 22:30
Wake: 03:02

Agora procure tarefas e eventos próximos de 03:02.

---

21. Verifique o Visualizador de Eventos

Abra:

eventvwr.msc

Procure eventos relacionados a:

Power-Troubleshooter
Kernel-Power

e correlacione com o horário.

---

22. Não trate todo Kernel-Power como falha

Kernel-Power registra diversos eventos relacionados a energia.

Nem todo evento indica problema grave.

Leia o contexto.

---

23. Verifique tarefas agendadas

Abra:

taskschd.msc

Examine:

• gatilho;
• horário;
• condições;
• ações;
• histórico.

Procure a opção relacionada a acordar o computador para executar a tarefa.

---

24. Compare o horário da tarefa com o wake

Se:

03:02 → PC acorda
03:02 → tarefa inicia

há forte correlação.

Se os horários forem muito diferentes, a hipótese perde força.

---

25. Teste o mouse

Se o mouse aparece como candidato, desabilite temporariamente sua capacidade de wake quando apropriado e repita o teste.

Não altere vários dispositivos ao mesmo tempo.

---

26. Teste o teclado

Faça o mesmo de forma controlada.

Lembre-se de que talvez seja necessário usar o botão de energia para acordar o computador durante o teste.

---

27. Teste a placa de rede

Se /lastwake ou os eventos apontarem para a rede, verifique propriedades como:

• Wake on Magic Packet;
• Pattern Match;
• opções de gerenciamento de energia.

Não desative Wake-on-LAN cegamente se você realmente usa esse recurso.

---

28. Diferencie Magic Packet de outros padrões

Uma boa configuração pode permitir wake apenas pelo evento realmente necessário.

Isso é melhor que simplesmente desativar toda capacidade de wake.

---

29. Considere Wi-Fi

Em notebooks, o adaptador sem fio também pode participar de comportamentos de energia.

Não limite a análise à Ethernet.

---

30. Teste docks e hubs USB

Se o problema ocorre apenas quando conectado a uma dock:

teste sem a dock

Se desaparecer, investigue os dispositivos apresentados por ela.

---

Modern Standby

31. Confirme pelo powercfg /a

Se o sistema utiliza Modern Standby, a análise precisa considerar que o comportamento é diferente do S3 clássico.

---

32. Gere SleepStudy quando aplicável

Use:

powercfg /sleepstudy

O relatório pode ajudar a analisar sessões de baixo consumo.

---

33. Use SleepStudy principalmente quando houver consumo anormal

Exemplos:

bateria descarrega enquanto dorme
notebook esquenta na mochila
sistema permanece ativo por longos períodos

Esses sintomas combinam bem com SleepStudy.

---

34. Não use SleepStudy como substituto do /requests

São perguntas diferentes:

/requests
→ quem está solicitando energia agora?

/sleepstudy
→ o que aconteceu durante sessões Modern Standby?

---

35. Gere systemsleepdiagnostics quando precisar de histórico de suspensão

Use:

powercfg /systemsleepdiagnostics

Esse relatório pode ajudar a entender transições de suspensão ao longo do tempo.

---

36. Use powercfg /energy como ferramenta complementar

Execute:

powercfg /energy

Quando quiser definir a saída:

powercfg /energy /output C:\Temp\energy-report.html

Certifique-se de que a pasta exista.

---

37. Não trate todos os avisos do energy report como causa

O relatório pode listar várias observações de eficiência energética.

A causa do seu sintoma precisa ser correlacionada com:

horário
+
comportamento
+
teste

---

Firmware e BIOS/UEFI

38. Verifique configurações de wake no firmware

Dependendo do fabricante, podem existir opções como:

Wake on LAN
Wake on PCIe
USB Wake
RTC Alarm
Power on by keyboard

Os nomes variam.

---

39. RTC Alarm merece atenção em wakes com horário fixo

Se o PC acorda diariamente no mesmo horário e o Windows não mostra timer claro, vale verificar o firmware.

---

40. Não altere todas as opções de BIOS de uma vez

Registre:

configuração original
↓
mudança
↓
resultado

---

41. Atualização de BIOS pode ajudar em casos específicos

Problemas de:

• ACPI;
• Modern Standby;
• USB wake;
• consumo em suspensão;

podem receber correções de firmware.

Mas atualização de BIOS deve seguir exatamente o procedimento do fabricante.

---

Procedimento rápido em duas trilhas

Trilha A — não entra em suspensão

1. powercfg /a
2. powercfg /getactivescheme
3. conferir tempo de suspensão
4. powercfg /requests
5. identificar processo/driver
6. descobrir atividade
7. teste A/B
8. atualizar/corrigir origem
9. verificar overrides
10. retestar

Trilha B — suspende e acorda

1. registrar horário
2. powercfg /lastwake
3. powercfg /devicequery wake_armed
4. powercfg /waketimers
5. Event Viewer
6. Power-Troubleshooter
7. tarefa agendada
8. dispositivos
9. firmware
10. retestar

---

Cenários práticos

Cenário 1 — vídeo mantém o PC acordado

Durante reprodução:

DISPLAY
SYSTEM

aparecem no /requests.

Ao parar o vídeo:

requests desaparecem

Comportamento esperado.

---

Cenário 2 — navegador fecha, mas request continua

A janela desaparece, porém processos continuam no Gerenciador de Tarefas.

Depois de fechar corretamente o navegador:

request desaparece

A causa estava na execução em segundo plano.

---

Cenário 3 — backup impede suspensão

Durante backup:

SYSTEM request

aparece.

Após conclusão:

request desaparece

Normal.

Criar override seria uma má ideia porque poderia permitir suspensão durante o backup.

---

Cenário 4 — driver de áudio mantém request

Nenhum som perceptível está tocando.

O /requests aponta áudio.

A investigação encontra um aplicativo de comunicação aberto em segundo plano.

Ao fechar:

request desaparece

A origem não era necessariamente o driver.

---

Cenário 5 — mouse acorda o PC

O PC suspende normalmente.

Minutos depois, acorda.

/lastwake aponta dispositivo de entrada.

Ao impedir temporariamente o wake pelo mouse:

PC permanece suspenso

Reativando:

wake volta

Causa confirmada.

---

Cenário 6 — placa de rede

O adaptador aparece como fonte repetida de wake.

Após restringir a configuração para o tipo de wake realmente necessário, o problema desaparece.

Esse é um diagnóstico melhor que desativar a placa de rede inteira.

---

Cenário 7 — tarefa agendada às 03:00

O PC acorda praticamente todos os dias às 03:00.

/waketimers mostra um timer correspondente.

O Task Scheduler confirma uma tarefa configurada para acordar o computador.

Depois de ajustar a condição:

wake deixa de ocorrer

---

Cenário 8 — notebook esquenta na mochila

O usuário acredita que “a suspensão não funciona”.

powercfg /a mostra Modern Standby.

SleepStudy revela atividade significativa em sessões de espera.

O diagnóstico correto passa a ser:

consumo excessivo no Modern Standby

e não necessariamente ausência completa de suspensão.

---

Cenário 9 — PC acorda em um segundo

O usuário clica em Suspender.

A tela apaga.

Um segundo depois volta.

Isso parece:

“não suspende”

mas /lastwake aponta um dispositivo.

Na realidade:

suspendeu
↓
acordou imediatamente

---

Cenário 10 — nenhuma ferramenta aponta claramente a origem

Faça testes controlados.

Tabela de exemplo:

Teste	Mudança	Resultado
1	mouse sem wake	acordou
2	teclado sem wake	acordou
3	Ethernet sem wake	permaneceu suspenso
4	Ethernet reativada	acordou

Esse método elimina hipóteses até encontrar a causa.

---

O que não fazer

Não execute comandos aleatórios de “otimização”

Problemas de suspensão precisam de diagnóstico, não de uma lista genérica de tweaks.

---

Não use requestsoverride como primeira solução

Você pode mascarar uma solicitação legítima.

---

Não desative todos os wake devices de uma vez

Você perde a capacidade de saber qual realmente causava o wake.

---

Não desative Wake-on-LAN se você precisa dele

Ajuste o mecanismo correto, quando possível.

---

Não atualize todos os drivers indiscriminadamente

Mude uma variável por vez.

---

Não redefina todos os planos de energia antes de coletar dados

Você pode apagar pistas importantes.

---

Não force S3 em hardware que não oferece suporte

Modern Standby e S3 dependem de implementação de hardware e firmware.

---

Não trate Modern Standby como defeito automaticamente

O comportamento é diferente do modelo clássico de suspensão.

---

Não conclua que o mouse é culpado apenas porque aparece em wake_armed

Lembre:

pode acordar
≠
acordou

---

Não conclua que uma tarefa é culpada apenas porque existe

O horário precisa fazer sentido.

---

Checklist final

[ ] Defini o sintoma correto
[ ] Executei powercfg /a
[ ] Verifiquei esquema ativo
[ ] Conferi tempos de energia
[ ] Executei powercfg /requests
[ ] Identifiquei requests ativos
[ ] Verifiquei processo/driver
[ ] Fiz teste A/B
[ ] Consultei requestsoverride
[ ] Executei powercfg /lastwake
[ ] Executei wake_armed
[ ] Executei waketimers
[ ] Consultei Power-Troubleshooter
[ ] Correlacionei horários
[ ] Verifiquei tarefas agendadas
[ ] Testei dispositivos um por vez
[ ] Verifiquei rede
[ ] Considerei USB/dock
[ ] Identifiquei Modern Standby
[ ] Usei SleepStudy quando aplicável
[ ] Consultei firmware se necessário
[ ] Confirmei a causa antes de considerar resolvido

---

FAQ — Windows 11 não entra em suspensão

1. Por que o Windows 11 não entra em suspensão?

Pode existir uma solicitação ativa de aplicativo, driver, dispositivo ou outra condição relacionada ao gerenciamento de energia.

---

2. Qual comando mostra quem está bloqueando a suspensão?

Comece com:

powercfg /requests

---

3. O que significa SYSTEM no powercfg /requests?

Indica uma solicitação relacionada a manter o sistema ativo.

A origem precisa ser identificada e interpretada.

---

4. O que significa DISPLAY?

Uma solicitação relacionada a manter a exibição ativa.

Isso pode ocorrer durante reprodução de mídia, por exemplo.

---

5. Um request significa que existe problema?

Não.

A solicitação pode ser completamente legítima.

---

6. Como saber se o programa realmente causa o problema?

Faça teste A/B:

programa ativo
→ request presente

programa fechado
→ request desaparece

---

7. O que é powercfg /requestsoverride?

É um recurso para configurar exceções a determinadas solicitações de energia.

Deve ser usado com cuidado.

---

8. Posso ignorar qualquer SYSTEM request?

Não.

A solicitação pode existir porque uma atividade realmente precisa continuar.

---

9. Por que meu PC apaga a tela mas não suspende?

Tela e suspensão possuem temporizadores e comportamentos diferentes.

---

10. Como descubro quais estados de suspensão meu PC suporta?

Execute:

powercfg /a

---

11. O que é S3?

É um estado tradicional de suspensão usado por muitos computadores.

---

12. O que é Modern Standby?

É um modelo moderno de baixo consumo que pode manter determinadas capacidades enquanto o sistema está em espera.

---

13. Todo Windows 11 suporta S3?

Não.

Isso depende do hardware e firmware.

---

14. Posso forçar S3 pelo Registro?

Não é recomendável assumir que isso será suportado pelo equipamento.

Primeiro consulte /a.

---

15. Como saber se meu PC acordou sozinho?

Depois do wake, tente:

powercfg /lastwake

---

16. O que é wake_armed?

É a lista de dispositivos configurados com capacidade para despertar o sistema.

---

17. Se o mouse aparece em wake_armed, ele causou o wake?

Não necessariamente.

---

18. Como vejo wake timers?

Use:

powercfg /waketimers

---

19. Uma tarefa agendada pode acordar o computador?

Sim, se estiver configurada adequadamente para isso.

---

20. Onde vejo tarefas agendadas?

Execute:

taskschd.msc

---

21. Como descubro qual tarefa acordou o PC?

Compare o horário do wake com:

• /waketimers;
• histórico da tarefa;
• Event Viewer.

---

22. Qual evento ajuda a investigar wakes?

Eventos do Power-Troubleshooter são particularmente úteis.

---

23. Kernel-Power 41 significa problema de suspensão?

Não necessariamente. O Event ID 41 costuma estar associado a desligamento ou reinicialização inesperados, e não deve ser usado como explicação genérica para qualquer problema de suspensão.

---

24. A placa de rede pode acordar o computador?

Sim, dependendo das configurações de wake do adaptador e do sistema.

---

25. Wake-on-LAN pode causar isso?

Pode participar de wakes, dependendo da configuração e dos eventos recebidos.

---

26. Preciso desativar Wake-on-LAN?

Não necessariamente.

Você pode precisar apenas ajustar quais eventos estão autorizados a acordar o PC.

---

27. O mouse pode acordar o PC sem eu mexer?

Pequenos movimentos ou vibrações podem gerar wake em alguns cenários.

---

28. USB pode causar problemas de suspensão?

Sim, determinados dispositivos e drivers podem participar de problemas de energia ou wake.

---

29. Como testar USB?

Desconecte dispositivos não essenciais um por vez e repita o teste.

---

30. Uma dock pode causar wake?

Pode, porque ela pode apresentar ao sistema vários dispositivos USB, rede, áudio e outros componentes.

---

31. O que é SleepStudy?

É um relatório útil para analisar sessões de Modern Standby em sistemas compatíveis.

---

32. Como gerar SleepStudy?

Use:

powercfg /sleepstudy

---

33. SleepStudy funciona em qualquer PC?

Sua utilidade está principalmente ligada a sistemas compatíveis com Modern Standby.

---

34. Para que serve systemsleepdiagnostics?

Ajuda a analisar informações históricas relacionadas às transições de suspensão.

---

35. Para que serve powercfg /energy?

Gera um relatório de diagnóstico de eficiência energética e configurações relacionadas.

---

36. O relatório energy mostra exatamente o culpado?

Não necessariamente.

Ele precisa ser interpretado junto com o sintoma.

---

37. BIOS pode fazer o computador acordar?

Sim. Recursos de wake também podem existir no firmware.

---

38. O que é RTC Alarm?

É uma função de firmware que pode permitir ligar ou despertar o computador em horário programado.

---

39. Atualizar BIOS pode resolver?

Em alguns casos relacionados a ACPI, energia e Modern Standby, uma atualização oficial pode ajudar.

Mas ela não deve ser feita aleatoriamente.

---

40. Qual é a melhor ordem de diagnóstico?

Para um PC que não suspende:

powercfg /a
↓
powercfg /requests
↓
processo/driver
↓
teste A/B

Para um PC que acorda:

powercfg /lastwake
↓
wake_armed
↓
waketimers
↓
Event Viewer
↓
teste de dispositivos

---

Conclusão

Quando o Windows 11 não entra em suspensão, a pior estratégia é começar alterando configurações aleatoriamente.

Primeiro determine se:

o sistema nunca entrou em suspensão

ou se:

entrou e acordou logo depois

No primeiro caso, powercfg /requests é uma das ferramentas mais úteis para localizar solicitações de energia feitas por processos e drivers.

No segundo, a investigação deve migrar para:

powercfg /lastwake
powercfg /devicequery wake_armed
powercfg /waketimers

e para os eventos de energia do Windows.

Em computadores modernos, powercfg /a também é essencial para descobrir se o sistema utiliza Modern Standby.

Quando esse modelo está presente, relatórios como:

powercfg /sleepstudy

e:

powercfg /systemsleepdiagnostics

podem revelar comportamento que não aparece em um diagnóstico tradicional de S3.

O principal é manter a investigação baseada em evidências:

sintoma
↓
comando correto
↓
origem
↓
teste controlado
↓
confirmação

Isso evita soluções genéricas e mostra exatamente qual programa, driver, dispositivo, tarefa ou configuração está interferindo no gerenciamento de energia.

Precisa de ajuda com suspensão, energia ou Windows 11?

A VMIA – Manutenção e Configuração realiza diagnóstico de problemas de suspensão, computadores que acordam sozinhos, drivers, dispositivos, configurações de energia e outros comportamentos anormais no Windows.

O atendimento pode ser feito por acesso remoto ou presencialmente, com agendamento.

Telefone e WhatsApp: (11) 99779-7772

Site: https://vmia.site

Blog técnico: https://vmia.com.br

WhatsApp: https://whats.vmia.com.br