Windows DLLBlocklist request form

: You can remove lines starting with a colon before attaching this to a bug.

1) How were we aware of the problem?
: In most cases, we're notified via crash reports.
: Before just blocking a suspicous module, we should spend some time on
: analyzing crash reports.

2) What is a suspicious product causing the problem?

3) Is the product downloadable?  If so, do we have a local repro?
: If we have a local repro of the issue, we might be able to come up with
: a fix on our side without blocking the module.
: If the product is downloadable, we should at least test it locally even
: though the issue is not reproducible.

4) Which OS versions does the problem occur on?
: You can minimize the impact by limiting the affected OS version
: to older Windows.

5) Which process types does the problem occur on?
: You can minimize the impact by blocking a module only on the browser
: process or sandboxed processes.

6) What is the maximum version of the module in the crash reports?
: You can specify this value in a new blocklist entry.

7) Is the issue fixed by a newer version of the product?
: If the issue is fixed by a newer version, upgrading the product is always
: an ideal solution, and which fact justifies blocking older versions.
: If not, we need to be careful because the product may no longer work after
: we block it.

8) Do we have data about the module in the third-party-module ping?
: The third-party-module ping captures a moment when the module is loaded,
: including the module's version, a process type where the module is loaded,
: and most importantly a callstack when the module is loaded.

9) Do we know how the module is loaded?
: Some injection techniques should not be blocked by our blocklist.
: Please read the page below for more information.
: https://wiki.mozilla.org/Blocklisting/DLL#Cases_where_we_should_not_block_a_module.

10) Describe your conclusion.