Como está seu japonês: link ?
Leva a uma entrada de KB ligeiramente útil:
link
Consider the following scenario:
- You have a custom networking application installed on your server.
- The application captures lots of traffic on the wire.
- The server may be using a DHCP-assigned IP address.
In this scenario, a large volume of disk I/O may be generated when writes are made to the C:\Windows\System32\wfp\wfpdiag.etl log.
This behavior is by design. When the Port Scanning Prevention Filter is triggered, this typically means that there is no process listening on the port. (For security reasons, WFP blocks process listening.) When a connection is tried on a port where there is no listener, WFP recognizes the packet as if it were coming from a port scanner and therefore silently drops the connection.
If there had been a listener, and the communication was instead blocked because of either malformed packets or authentication, the dropped event would be listed as “DROP” (not silent), and WFP logging would indicate a different filter ID and name.
This filter is built in to the Windows Firewall and Advanced Security (WFAS). It is included in Windows Vista, Windows Server 2008, and later versions of Windows.
A solução alternativa listada permite adivinhar a chave de registro, onde você deve adicionar a dword CollectNetEvents com um valor 0 under.
Felizmente, a postagem do blog sugere netsh, você pode despejar um .xml de wfpdiag.etl com netsh wfp show netevents e
desabilite-o com netsh wfp set options netevents=off de um prompt elevado, o que também cria a chave de registro mencionada acima em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Options
Note By disabling WFP logging, this only stops the logging of WFP activity in wfpdiag.etl. The Port Scanning Prevention Filter continues to work normally.