A PXIe-8135 in a PXIe-1065 that shows one PCI-to-PCI bridge in Device Manager, no chassis in NI MAX, and no PXIe-5630 or PXIe-2547 in their soft front panels has a topology problem below the driver layer. The controller boots, Device Manager is free of warnings, and the NI SMBus Controller is listed, yet nothing behind the system slot is visible. A reference 8135 + 1065 pair restored to the default NI Windows 7 image detected the chassis after installing only PXI Platform Services 18.0, with no BIOS changes. That pair defines the target state: the software stack is sufficient when the hardware link is healthy.
Software-layer fixes that leave the enumeration fault untouched
Each of the usual fixes acts above the layer where this failure sits. Every one has already been tried on this system without effect.
| Fix attempted | Why it fails here |
|---|---|
| Reset the MAX database | Rebuilds MAX's cache of what the OS reports. It cannot create devices the OS never enumerated. |
| Reinstall Windows 7 (32-bit and 64-bit, base and SP1) | Replaces the software that reads the bus. It does not change the link between controller and backplane. |
| Try PXI Platform Services v18.0 through v20.5 | Platform Services builds the chassis entry from the enumerated topology. The known-good pair works with 18.0, so a version mismatch is not the variable. |
| Change BIOS options such as 64-bit Memory Mapped IO | That option only relocates large BARs. It has no effect when no downstream devices exist to receive resources. The known-good pair needed no BIOS toggles. |
| Flash or roll back BIOS (both available versions tried; the unit shipped with 1.2.10f0) | Neither version changes link behavior on this unit. |
| Add the chassis manually in MAX | MAX offers no add-chassis option here. The .ini file for the PXIe-1065 is already present, so a missing definition is not the cause. |
| Pull updates through the NI Update Service | The service times out or returns a server error on this controller, so it is not a usable path. Use the downloadable 8135 firmware and additional drivers package instead. |
PCI-to-PCI bridge count as the deciding quantity
A PXIe controller reaches the peripheral slots through a PCI Express link routed via the system-slot connector to the backplane's PCIe fabric. At power-up the BIOS walks the tree: root port, then the chassis switch's upstream and downstream ports (which Windows lists as PCI-to-PCI bridges), then the modules. If the link does not train, the switch ports never exist, so there are no bridges and no module devices. PXI Platform Services, MAX, and the soft front panels read that enumerated topology. They cannot fabricate a bus.
Reports for working systems expect two or more PCI-to-PCI bridges. This system shows one. The decisive measurement is the bridge count on a working reference. Take the reference from the PXIe-8101 running in the same PXIe-1065, since that pair worked, and compare its Device Manager tree (View > Devices by connection) with the 8135's tree.
Two observations that look reassuring carry no weight here:
- The NI SMBus Controller in Device Manager shows that the driver loaded. It does not prove the PCIe data link trained.
- No warnings in Device Manager only covers devices that enumerated. A device that never appears raises no error.
Quantities to capture and where to read them
| Quantity | Healthy reading | Where to read it |
|---|---|---|
| PCI-to-PCI bridge count | Matches the 8101 in the same 1065 (this system's 8135 shows one) | Device Manager, Devices by connection, under the PCI Express root ports |
| Chassis and controller entry | PXIe-1065 listed with the PXIe-8135 selected as controller | NI MAX, Devices and Interfaces |
| Module presence | PXIe-5630 and PXIe-2547 listed, self-test passes | NI MAX, right-click module, Self-Test |
| BIOS version | Record it; the reference pair ran 1.01f, this unit shipped with 1.2.10f0 | BIOS setup screen at boot |
| Controller hardware revision | Compare against the release notes in the 8135 firmware and additional drivers package | Serial number label on the controller |
Serial-number review matters because this unit is an earlier revision for which issues have been reported. The serial number also indicates it supports full Windows rather than RT mode only, so an OS-mode restriction is excluded.
Isolating the controller from the chassis
The PXIe-1065 ran correctly with the PXIe-8101, which makes the chassis backplane the less likely fault. The PXIe-8135 is the untested variable. The isolation sequence follows.
- Power down. Seat the PXIe-8101 in the 1065 and record its Device Manager bridge tree. This is the topology reference for this chassis.
- Seat the PXIe-8135 in a different PXIe chassis, if one is available. If the 8135 detects that chassis, the fault is in the 1065 system slot or backplane connector. If the 8135 fails there too, the controller's PCIe path is the fault.
- Confirm the peripheral modules are PXIe, not PXI or cPCI. Slot placement was already confirmed for the VNA and multiplexers (all PXIe, slot 8 and higher), so this step only rules out a mismatch on any other module.
- Remove every peripheral module and boot the 8135 with the chassis empty. Compare the bridge count with the 8101's empty-chassis count. This separates a controller-to-backplane link fault from a fault caused by a single module.
Backplane and connector inspection
A bent or recessed pin in the system-slot connector interrupts one or more PCIe lanes or sideband signals. That produces the profile seen here: the controller boots and runs normally because its own resources are intact, while the chassis fabric never comes up. An early visual check found nothing, but a rough look does not clear it. Repeat it deliberately.
- Power off and remove the controller. Inspect the chassis system-slot connector and the controller's mating connector under magnification and angled light. Look for bent, recessed, or displaced contacts and debris.
- Reseat the controller with the ejector handle fully latched and the front-panel screws tightened. A partial seat can train fewer lanes or none.
- Re-check the bridge count after each reseat. A change in count, even without full success, confirms a physical link problem.
Rebuilding the stack in the known-good order
This unit shipped without a hard drive, so the Acronis recovery partition that normally restores the default NI Win7 image (F4 at boot) is absent. If the 8135 bridge count matches the reference after the hardware checks, rebuild to match the reference configuration.
- Install Windows 7 64-bit (the reference pair used 64-bit).
- Install the 8135 firmware and additional drivers from NI's download page for the PXIe-8135. The install order used so far was chipset, GPU (ATI), Intel RST, network, USB 3.0.
- Install PXI Platform Services 18.0, the version proven on the reference pair.
- Reset the MAX database once, after the topology is correct, not before.
- Install only the driver for one module first (NI-SCOPE was sufficient on the reference pair), and confirm it enumerates before adding the rest.
The old PXIe-8101 drive is useful for retrieving installers and configuration files. The 8101 chipset differs from the 8135's, so install the 8135 chipset drivers fresh instead of relying on an image carried over.
Reading MAX when the chassis entry is missing
The PXIe-1065 worked with the 8101 without appearing as a chassis in MAX. A missing chassis entry alone therefore does not prove a fault; modules listed under Devices and Interfaces are the reliable indicator. The 8135 fails on both counts, since the VNA and multiplexers are also absent, which is why the bridge count is the correct primary check. For a working system, the chassis appears under Devices and Interfaces with the correct controller and chassis selected automatically, with modules listed beneath it.
Acceptance checks after the fix
- Device Manager bridge count on the 8135 equals the count recorded from the 8101 in the same chassis.
- MAX Devices and Interfaces lists the PXIe-1065 with the PXIe-8135 as controller.
- The PXIe-5630 and PXIe-2547 appear in MAX and pass Self-Test.
- Each module's soft front panel opens and finds its hardware.
- A cold power cycle of the chassis repeats the result. A link that trains once but fails after cold boot indicates a marginal connector seat.
FAQ
Can I add a PXIe-1065 manually in NI MAX if it is not detected?
Not on this system: MAX offers no add-chassis option even though the PXIe-1065 .ini file is present. Fix enumeration first, meaning the PCI-to-PCI bridge count, then let PXI Platform Services create the entry.
Does a PXIe-8135 need BIOS changes to work in a PXIe-1065?
No. A reference pair restored to the default NI Win7 image detected the chassis after installing PXI Platform Services 18.0, with no BIOS toggles. Enabling 64-bit Memory Mapped IO and moving between both available BIOS versions made no difference on this unit.
Does a chassis missing from NI MAX mean the modules will not work?
Not by itself. The PXIe-1065 ran with the PXIe-8101 without being listed as a chassis in MAX. Judge by whether modules appear under Devices and Interfaces and pass Self-Test.
Can I stop troubleshooting and escalate to NI support?
Escalate once the 8135 also fails in a second PXIe chassis or the bridge count stays below the 8101 reference after a clean connector inspection and reseat. Give NI support the controller serial number, BIOS version, PXI Platform Services version, and the Device Manager bridge trees from both controllers, and ask about the hardware revision history of your unit.