LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to disable the nipcibrd.sys driver to prevent hibernation-resume BSOD (Windows 11)?

Solved!
Go to solution

Since I installed Labview 2022 Q3 (with drivers between 2022 Q3 and 2023 Q1) on a new Windows 11 PC, I'm getting sporadic DRIVER_POWER_STATE_FAILURE bluescreens when resuming from hibernation, about 20-30% of the time. The cause is the nipcibrd.sys driver (FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_nipcibrd_IMAGE_pci.sys). This has been a well-known issue at least since Labview 2019 but it was never fixed until now, probably because it only occurs on certain mainboards and would be too much to bother with.

 

If I'm not mistaken, the nipcibrd driver is part of the PXI platform services package. I'm not using any NI hardware on this PC, so I don't need this driver, but I can't remove the PXI platform services package because many other modules which I use (even without locally attached NI hardware) depend on it (VISA, Vision, DAQmx etc.). And even though no NI hardware is attached (no NI devices show up in device manager), the driver is still loaded, causing the occasional BSOD when resuming from hibernation. I tried to prevent this driver service from starting, but changing its startup mode from "boot" to "manual" or "disabled" causes a BSOD on boot with INACCESSIBLE_BOOT_DEVICE (😲) until I set the registry entry for the startup mode back to "boot" using an offline recovery environment.

 

How can I properly disable the nipcibrd driver without crashing the PC on boot and without uninstalling the PXI platform services?

Message 1 of 8
(3,372 Views)

Well, IMO (and really, this is just my opinion) hibernation is BAD for hardware.  Hardware never seems to come back from hibernation in a "normal" state.  I disable hibernation on any computer that I use, especially test stations.  And if I can't - like some UPS shutdown modes require it - the first thing I do when it comes back to life is reboot the computer.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 2 of 8
(3,333 Views)

It's not a test station, it's a work station. Hibernation is absolutely crucial here for productivity because I want to continue the next day where I left it last night without having to restart all the programs and reopen all the documents and projects in the previous state. I also don't want to let it run 24/7 and idling away energy for nothing. In a production or lab environment it's a different story, those machines are critical and should run 24/7 (but then nobody should run Windows on those in the first place if "ultra reliability" is the goal).

 

But that's all beside the point that a driver shouldn't cause a BSOD on resume from hibernation, especially if it's supposed to be inactive when no NI hardware is used. If the driver causes this kind of critical error, who is to say it won't crash during normal use even if hibernation is disabled? In the thread I linked there were other problems reported with the driver, not just the hibernation BSOD.

 

In any case, since NI wasn't willing to fix it since (at least) 2019, I just want to know a way to safely disable/remove this (unused!) driver without uninstalling half of the programming environment.

0 Kudos
Message 3 of 8
(3,301 Views)
Solution
Accepted by Novgorod

Ok, nevermind. The nipcibrd driver can be removed using its MSI installers (pciBrdI32.msi and pciBrdI64.msi) which are packaged into the PXI platform services installer. The driver can NOT be uninstalled individually through the NI package manager without forcing you to also uninstall a ton of dependencies, but using the MSI installers directly works just fine. The driver service is completely removed and doesn't crash the startup. It also doesn't seem to affect any of the "dependent" Labview support for DAQmx, VISA and Vision as long as you don't use NI hardware. Most certainly the driver will be reinstalled next time the PXI platform services package gets updated, so don't forget to remove it again after each update.

Message 4 of 8
(3,264 Views)

Thanks, this worked for me also (I had a different BSOD from nipcibrd.sys).

 

It took me a little while to figure out how to get the msi files. Here's more detailed instructions that worked for me.

  1. Download the offline installer from: https://www.ni.com/en-us/support/downloads/drivers/download.pxi-platform-services.html#479592 You can find the version you currently have installed in the NI package manager (I had 2022 Q3)
  2. Mount the downloaded iso
  3. Navigate to the pool directory
  4. using 7-zip, open ni-pcibrd_22.5.0.49208-0+f56_windows_x64.nipkg (version may be different)
  5. double click on data.tar.gz
  6. double click on data.tar
  7. double click on the . folder
  8. extract the 5 files, which includes pcibrdi32.msi and pcibrdi64.msi
  9. Run both msi's, choosing the uninstall option.

 

Message 5 of 8
(2,909 Views)

There is likely one thing that won’t work anymore even without using any NI hardware and that is a VISA USB raw driver that you can generate with the VISA driver wizard. Of course this is an esoteric use case and with recent Windows requirements to only load signed drivers anymore, a mostly academic concern too. Anyone still using that rather than a real dedicated device driver is probably still running on Windows XP or earlier.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 8
(2,874 Views)

Thank you! I have gone through the (very emotional and perplexing) process as well. In my case (ThinkPad P1) installing the latest PXI-platform services via the package manager already fixed the issue. The corresponding nipcibrd driver files got updated and all have a date tag of 23.09.2023, which might indicate that NI finally fixed the issue in parts of their software. 

 

Crash log:

In my case the PC did not even boot because of nipcibrd.sys after installation of the latest NI MAX, with message: SECURE_PCI_CONFIG_SPACE_VIOLATION

a temporal fix to boot the PC was disabling the VT-d virtualization service in the BIOS menu.

In my case afterwards the PIN services were not working properly for logging in to the PC. So make sure you have internet connection and your microsoft-account available. Booting in safe mode, also with network drivers, in the first place (not understanding what was happening) caused an annoying PIN loop.

 

I hope this might help others.

0 Kudos
Message 7 of 8
(2,230 Views)

@maexchen wrote:

In my case (ThinkPad P1) installing the latest PXI-platform services via the package manager already fixed the issue. The corresponding nipcibrd driver files got updated and all have a date tag of 23.09.2023, which might indicate that NI finally fixed the issue in parts of their software. 


Uuh, you're saying there's hope? I'm too scared to try. Well, I might inadvertently anyway next time I update anything, since I'll have definitely forgetten about this issue by then.

0 Kudos
Message 8 of 8
(1,780 Views)