TraceEvent + CaptureState Issue from https://github.com/microsoft/perfview/pull/2222 #2279
Description
#2222 introduced a change that OR'd the capture state flags with the previously enabled flags, however following the xperf commands from the log.cmd (gpuview) script, this seems wrong. It can leads to a scenario where you can unintentially get duplicate events in the capture vs the no capture sessions.
From the log.cmd (verbose option) from gpuview as an example (pasted below), we see that there are two log files created, one CaptureState.etl and another NoCaptureState.etl.
Let's simply and only look at {802ec45a-1e99-4b83-9920-87c98277ba9d:0x80900236} (Microsoft-Windows-DxgKrnl) provider.
The first command enables the DxgKrnl provider with 0x80900236 flags set for the CaptureState session name.
The second sets capture state 0x90FFFF flags for the CaptureState session name (without modifying the enabled flags of the first command)
The third enables the DxgKrnl provider 'NoCaptureState' session, with 0x208041 flags, which are unique flags compared to the CaptureState session.
You can see that every other provider in the CaptureState session is unique from the NoCaptureState one.
Now, with the fix from #2222, now it's essentially:
Xperf -start CaptureState -on 802ec45a-1e99-4b83-9920-87c98277ba9d:0x8090FFFF:5
Xperf -capturestate CaptureState 802ec45a-1e99-4b83-9920-87c98277ba9d:0x90FFFF:5:'stack'
Xperf -start NoCaptureState -on 802ec45a-1e99-4b83-9920-87c98277ba9d:0x208041:5:'stack'
which ends up duplicating several bits between the two sessions, and the merged output file shows both duplicated events.
My concern is that if we were to follow guidance from sources like log.cmd (which sets up providers and flags based on some verbosity), than the output of TraceEvent would contain duplicates compared to what Xperf outputs. Is the only solution to ensure that Capture vs other sessions have unique flags? How does xperf do it?
This screenshot may help show what I mean. By using logman query -ets, we can see what keywords are being used. (this was using the log.cmd min command). Before or after the -capturestate command, the Keywords are the same (0x800). The difference is that that -capturestate command caused the provider to immediately write the flags from -capturestate to be written. Everything else remains the same.
Log.cmd verbose:
`
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview> Xperf -start CaptureState -on 802ec45a-1e99-4b83-9920-87c98277ba9d:0x80900236:5+a688ee40-d8d9-4736-b6f9-6b74935ba3b1:0xffff:5+CA11C036-0102-4A2D-A6AD-F03CFED5D3C9:0xf:6:'stack'+03bbe5b8-c788-4d0b-b47e-5b5731398a89+a0ab5aac-e0a4-4f10-83c6-31939c604fd9:0xffffffffffffffff:6:'stack'+c0c418c5-1f3c-4ee0-93a2-a0bb8f417f9a:0xffffffffffffffff:6:'stack'+5d8087dd-3a9b-4f56-90df-49196cdc4f11:0xffffffffffffffff:6:'stack'+db6f6ddb-ac77-4e88-8253-819df9bbf140:0xffffffffffffffff:6:'stack'+7E7D3382-023C-43cb-95D2-6F0CA6D70381:0x1+2d4ebca6-ea64-453f-a292-ae2ea0ee513b:0xf:5+783ACA0A-790E-4d7f-8451-AA850511C6B9:0xf:6+356E1338-04AD-420E-8B8A-A2EB678541CF:0xf00000:5+19d9d739-da0a-41a0-b97f-24ed27abc9fb:0xffffff:5+Microsoft-Windows-Kernel-Power:0xffffffffffffffff:0xff+Microsoft-Windows-Kernel-Processor-Power:0xffffffffffffffff:0xff+Microsoft-Windows-Kernel-Pep:0xffffffffffffffff:0xff -BufferSize 64 -MinBuffers 120 -MaxBuffers 480 -f CaptureState.etl
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview> Xperf -capturestate CaptureState 802ec45a-1e99-4b83-9920-87c98277ba9d:0x90FFFF:5:'stack'+a688ee40-d8d9-4736-b6f9-6b74935ba3b1:0xffff:5+CA11C036-0102-4A2D-A6AD-F03CFED5D3C9:0xf:6:'stack'+03bbe5b8-c788-4d0b-b47e-5b5731398a89+a0ab5aac-e0a4-4f10-83c6-31939c604fd9:0xffffffffffffffff:6:'stack'+c0c418c5-1f3c-4ee0-93a2-a0bb8f417f9a:0xffffffffffffffff:6:'stack'+5d8087dd-3a9b-4f56-90df-49196cdc4f11:0xffffffffffffffff:6:'stack'+db6f6ddb-ac77-4e88-8253-819df9bbf140:0xffffffffffffffff:6:'stack'+7E7D3382-023C-43cb-95D2-6F0CA6D70381:0x1+2d4ebca6-ea64-453f-a292-ae2ea0ee513b:0xf:5+783ACA0A-790E-4d7f-8451-AA850511C6B9:0xf:6
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview> Xperf -start NoCaptureState -on DX+531A35AB-63CE-4BCF-AA98-F88C7A89E455:0xffff:5+ee685ec4-8270-4b08-9e4e-8b356f48f92f:0:0x12+802ec45a-1e99-4b83-9920-87c98277ba9d:0x208041:5:'stack'+f404b94e-27e0-4384-bfe8-1d8d390b0aa3+362007f7-6e50-4044-9082-dfa078c63a73:0x000000000000ffff:0x5+8f2048e0-f260-4f57-a8d1-932376291682+8cc44e31-7f28-4f45-9938-4810ff517464:0xffff:6+30336ed4-e327-447c-9de0-51b652c86108+8c416c79-d49b-4f01-a467-e56d3aa8234c:0xffff+a42c77db-874f-422e-9b44-6d89fe2bd3e5:0x000000007fffffff:0x5+8c9dd1ad-e6e5-4b07-b455-684a9d879900:0xFFFF:6+9e9bba3c-2e38-40cb-99f4-9e8281425164:0xFFFF:6+044a9015-d96c-5dd1-0199-72d258325298:0xFFFF:6+31293f4f-f7bb-487d-8b3b-f537b827352f+42C4E0C1-0D92-46f0-842C-1E791FA78D52+28cf047a-2437-4b24-b653-b9446a419a69+a6a00efd-21f2-4a99-807e-9b3bf1d90285:0x000000000000ffff:0x5+a0386e75-f70c-464c-a9ce-33c44e091623:0xffff:5+ab604427-d048-4139-8494-1246c81f09d5:0xffffffffffffffff:6:'stack'+7b4dc3d4-29a1-4599-8930-9ea9001686d2+712909c0-6e57-4121-b639-87c8bf9004e0+dcb453db-c652-48be-a0f8-a64459d5162e:0:5+f8f10121-b617-4a56-868b-9df1b27fe32c:0xffff:5+6e03dd26-581b-4ec5-8f22-601a4de5f022:0xffff:5+681069c4-b785-466a-bc63-4aa616644b68:0xffff:5+75d4a1bb-7cc6-44b1-906d-d5e05be6d060:0xffff:5+63770680-05F1-47E0-928A-9ACFDCF52147:0xffff:5+779d8cdc-666b-4bf4-a367-9df89d6901e8:0xffff:5+292a52c4-fa27-4461-b526-54a46430bd54::6+ea6d6e3b-7014-4ab1-85db-4a50cda32a82:0xffff:5+7b4dc3d4-29a1-4599-8930-9ea9001686d2+F1FF64EF-FAF3-5699-8E51-F6EC2FBD97D1:0xffffffffffffffff:6:'stack'+70e74dd8-39db-5f6f-6fd1-f5581b29e834:0xffff:5 -BufferSize 64 -MinBuffers 120 -MaxBuffers 480 -f NoCaptureState.etl
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview> Xperf -stop CaptureState
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\gpuview> Xperf -stop NoCaptureState
`