Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Disabling WPP

EmjayenEmjayen Member Posts: 6
edited March 14 in NTDEV

Is there an administrative toggle to disable WPP tracing? Or would this require recompilation of the driver (of which is not an option, as it's not mine)

The reasoning in this case being that a performance-critical path is tied up in WppAutoLogTrace, accounting for ~65% of time.


  • MBond2MBond2 Member Posts: 535

    WPP is designed to be lightweight. It would be a surprise if it represented a significant performance issue in a driver. WPP consumers can be enabled or disabled, but if a driver is a producer, then those calls can't be removed without building a new version

  • EmjayenEmjayen Member Posts: 6

    Figured as much; that's unfortunate. It certainly is the culprit in this instance however

    A bit of hacking to remove the call-site also confirms it.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 525
    via Email
    If WPP runs in a path that is CPU intemsive but small, it easily makes the
    path underperforn.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,556

    Looks like this is the WPP Recorder. There are some per-driver settings that you can configure in the Registry:

    Maybe this driver is using an unusual configuration? Also, what's the perf scenario and how are you capturing the perf data?


  • MBond2MBond2 Member Posts: 535

    This looks like a partial screenshot from one of the Intel tools. If that's the case, then it is far from certain that the high CPU time you observe here is actually indicative of a performance problem CAUSED by this function. Your remark about hacking is more suggestive, but it is hard to know.

    A pure guess is that you are testing some kind of network application, and you are looking at some kind of metric of single connection throughput. Its a pure guess, but it might fit the situation that you describe

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,482

    I'm not sure what you're trying to say here. Intel's performance analysis tools are among the best in the industry. If it suggests that 64% of CPU time is being spend in WppAutoLogTrace, then the reality is probably pretty darned close to that.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MBond2MBond2 Member Posts: 535

    I have worked with the Intel tools for many years - since from when they were new in the early 2000's. I don't doubt that the tool reports the correct value, and that 64% of the observed CPU time was taken by that function, but the question remains whether any of that CPU time actually contributed to a performance problem.

    Assuming that these numbers come from hotspot or lightweight hotspot analysis, if the CPU has not been maxed out during the test, it is very likely that the thread context that this CPU usage happens in is irrelevant to the overall performance problem being investigated. The key is to look at the call stack views (top down / bottom up). We simply don't have enough information to provide useful suggestions

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 525
    via Email
    ? If the path is a hotpath, any CPU usage decreases performance.
  • MBond2MBond2 Member Posts: 535

    But is the path a hot path? Hot spot analysis does not tell you that. Hot spot analysis tells you that user a certain sample frequency, the observed location of the IP of threads running on not idle cores was X. And for each number of times X was observed, or some other cut of the call stack, a percentage is derived.

    if the observed location is at the bottom of a tight loop, or the system has been maxed out (CPU usage), then these metrics are reliable sources of performance problems. otherwise, they might be performance problems or incidental waste, or offloaded work that actually increases the performance of the critical path by moving work like logging onto otherwise idle cores / threads

    fining out which callstack is a performance critical path is not so easy using these tools. If you already know which one is performance critical, then it is easy to filter out everything else and focus on the stalls that ordinarily or might occur along that path

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online
Writing WDF Drivers 22 May 2023 Live, Online