Active Processes not populated / Many Exploration patterns like MSSQL db on windows does not get triggeredDescription: If patterns like MSSQL db etc on windows doesn't get triggered even though these processes are fetched as part of Active Processes probe. This may happen because the payload xml fetched as part of the Active Process probe is incorrectly formatted or it has some garbage values. Due to which the process classifiers are not triggered for the respective process This can be mitigated in the below ways. i. Sometimes any of the fetched processes may have unsupported character which may also lead to parsing issues. These characters are generally found in the Command Line CIM property . Hence on can fetch running processes data sans the "CommandLine" field as this causes an issue during parsing.I would be wise to disable the wmi field Win32_Process.CommandLine in the below probe as this won't query for the command line for running processes.https://<instance>.com/discovery_probes_wmi.do?sys_id=8ef5a7990a0a0ba5007a9d00e48e5e00after which the running processes will be populated if thats the culprit. ii. Check if the mid is configured to run the WMI or WINRM queries if the latter then change it to default behaviour mid.windows.management_protocol to WMI. Rerun the discovery and check the active processes ecc input queue it should not contain any error If it contains error like below Permission Denied issue then re-configure credentialswith proper admin share access. Please check the below KB for same - KB0753738https://support.servicenow.com/kb?id=kb_article_view&sys_kb_id=74e16b16db6ebb006064eeb5ca9619dd <error>New-CimSession : Access is denied.At line:1 char:1+ New-CimSession -ComputerName $Host -SessionOption $so -Credential $Credential+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ CategoryInfo : PermissionDenied: (:) [New-CimSession], CimException+ FullyQualifiedErrorId : HRESULT 0x80070005,Microsoft.Management.Infrastructure.CimCmdlets.NewCimSessionCommand+ PSComputerName : 10.8.1.201</error></result> The above is a workaround we have an existing defect DEF0201247. - This would strip invalid XML characters in WMIRunner