Rebalance is tested by selecting the target device and clicking the Test Rebalance button. When you press this button, a separate window appears. Select your desired mode of rebalance from this window.

As with the removal test, the test application attempts to add an upper filter to the target device stack and then restart the device stack by using SetupDiCallClassInstaller with DIF_PROPERTYCHANGE. If this attempt is not successful (that is, if someone on the target device stack failed the query-remove IRP), you might need to restart the computer to test rebalance.

Depending on the mode of rebalance that you choose, the test might take the following possibilities:

1. Simple: This option initiates a rebalance procedure which results in the IRP_MN_QUERY_STOP_DEVICE PnP IRP to the device driver.

   If any driver in the stack fails this IRP the rebalance procedure is abandoned. Please note that in Windows Vista, there is support for multi-level rebalance. If a rebalance is started on a non-leaf device node, all of the device stacks that are present in the device tree with that device node as the root also go through rebalance. And if any of the child device stacks fails query stop, the whole rebalance procedure is abandoned. So drivers must not fail query stop without a genuine reason to do so. If this failure happens, the PnP manager sends cancel stop (IRP_MN_CANCEL_STOP) to all the device stacks that had been sent query stop.

   If all of the device stacks involved pass query stop, the test continues with the rebalance and sends the IRP_MN_QUERY_RESOURCE_REQUIREMENTS and IRP_MN_FILTER_RESOURCE_REQUIREMENTS IRPS to find the resource requirement of the devices.

   After this point, two different paths are possible depending on whether the target device consumes any resources or not:

   1. If the device does not consume any resources, the PnP manager itself sends a cancel stop (IRP_MN_CANCEL_STOP_DEVICE) as an optimization.
   3. If the device actually consumes resources, the rebalance procedure is completed with the IRP_MN_STOP_DEVICE and IRP_MN_START_DEVICE IRPs.

   With this option, the resources of the device do not change.

2. FailQueryStop: This option initiates a rebalance procedure, but the filter driver deliberately fails the query stop. The order of IRPs looks like IRP_MN_QUERY_STOP_DEVICE (which is failed by the filter driver while coming up, causing a cancellation of rebalance) and IRP_MN_CANCEL_STOP_DEVICE.

   With this option, the resources of the device do not change

3. NewResources: This option initiates a rebalance and also manipulates the resource requirement of the device to maximize the chances that actually new resources are allocated to the device. This option also helps a device with no resources to actually go through the complete rebalance procedure:
   1. First the simple rebalance is started, causing the following IRPs:
      • IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the drivers. The test already covered the case where this IRP is failed.)
      • IRP_MN_QUERY_RESOURCE_REQUIREMENTS
      • IRP_MN_FILTER_RESOURCE_REQUIREMENTS. In response to this IRP, while going up, filter driver takes action based on whether the device consumes any resources or not:
        • If the device has no resource requirement, filter assigns a fake resource.
        • If the device has a resource requirement, it tries to restructure the resource requirement list in such a way that maximizes the probability of changing the current assignment. For example, if a device needs 2 bytes of memory anywhere between 00 to FF and currently is assigned 3A-3B, modify such that the new resource requirement (in order of preference) looks like 00-39 or 3C-FF or 3A-3B. Similarly if the device resource requirement list has any alternate requirements, it will change their order so the alternate requirement comes earlier in the list.
   2. Now the device should always complete the rebalance procedure.

      IRP_MN_STOP_DEVICE

      IRP_MN_START_DEVICE (The new allocated resources. If fake requirements were created, mask the new resources from the actual drivers.)

4. Fail Restart: This option initiates a rebalance but when the filter driver gets the start after the rebalance, it deliberately fails it–which causes the surprise removal IRP followed by Removal IRP.

   First, it starts the rebalance procedure and makes sure that the driver gets a stop and a start by generating fake resource requirement for a device which does not consume any resources.

   • IRP_MN_QUERY_STOP_DEVICE (assuming this IRP is passed by all the drivers. The test already covered the case where this IRP is failed.)
   • IRP_MN_QUERY_RESOURCE_REQUIREMENTS
   • IRP_MN_FILTER_RESOURCE_REQUIREMENTS (If the actual resource requirement are null, filter assign fake resource requirement, so there is a stop and a start.)
   • IRP_MN_STOP_DEVICE
   • IRP_MN_START_DEVICE (The filter fails this IRP while going up. This action causes the surprise remove IRP.)
   • IRP_MN_SURPRISE_REMOVAL
   • IRP_MN_REMOVE

   After the rebalance test is complete, the device will be uninstalled and reenumerated, also removing the filter driver from the stack.