Plextor PX-M402U no preview / no Record button in WinDVD Creator 2

[OS_Man]

Hi everyone,

I know this is a very old device and there was already a discussion here around 2007 about the Plextor ConvertX PX-M402U, but since that thread is almost 20 years old, I decided to open a new topic and ask for help again.

I recently bought a second-hand Plextor ConvertX PX-M402U from eBay (seller from the USA). The original Plextor application CD is included, with the original serial number for InterVideo WinDVD Creator 2 printed on the sleeve.

I have been trying to get the device working for analog video capture, but I am running into the same problem on multiple systems.

Systems tested:

Microsoft Windows XP SP3 32-bit
Microsoft Windows 7 Ultimate SP1 32-bit

What happens:

The device is detected correctly in Device Manager
Drivers install without warning icons
The blue power LED turns on
BUT the capture LED never turns on
In WinDVD Creator 2, the preview window is black
“Record” and “Input Source” controls are missing/inactive in the Capture section
No video or audio preview appears

I also tested with several other capture applications:

AMCap
VirtualDub
Ulead VideoStudio 8
Nero Vision

Results:

AMCap sometimes gives “Unable to render the video capture stream”
VirtualDub gives Error 418 / no capture device detected
Nero Vision briefly reacts to audio detection but still no preview
No software is able to start actual capture

I also noticed another strange thing:

Inside WinDVD Creator 2, under the Help menu, there is an “Activation” option asking for:

Plextor account
email/password
even the last 4 digits of the original credit card

However:

the software never shows “trial”
there is no activation error during startup
the serial number from the original CD sleeve is accepted normally

So I am wondering:

Could the missing Record/Input Source buttons somehow be related to activation or licensing?

Or is this more likely a DirectShow / WDM driver / capture filter issue on modern Windows systems?

Another question:
Which OS is generally considered the most compatible for the PX-M402U?

XP SP2?
XP SP3?
Windows 7 32-bit?
something else?

If anyone here has previously used this device successfully, especially on Windows 7, I would really appreciate any advice, driver recommendations, required runtimes/codecs, or installation order suggestions.

Thanks a lot.

[jwillis84]

It was based on the old GO7007SB mpeg chip.

The 32-bit Windows reality

Plextor only ever shipped 32-bit XP drivers for the PX-M402U/TV402U; that's what every long-suffering Tom's Hardware and VideoHelp thread on the topic boils down to. ADS Tech shipped 32-bit XP drivers as the production release for the DX2.

The "709 Vista Candidate" for ADS Tech DX2— yes, that was real
ADS Tech released a beta/pre-release Vista driver bundle, distributed as 709_Vista_Candidate (sometimes paired with 714_Vista_Candidate for a sibling product). It was the closest thing to a 64-bit driver anyone in this family ever produced. Caveats matched your recollection:

• It was unsigned (or improperly signed) — to load it on 64-bit Windows 7 you had to boot with Disable Driver Signature Enforcement every time (EasyBCD was the popular workaround).
• The official ADS Tech instructions only claimed support for 32-bit Windows 7 via the Vista Candidate; the 64-bit usage was a community trick.
• The recipe was: plug the DX2 in, let the install fail, then point Device Manager → Sound, Video and Game Controllers → unknown device at the 709_Vista_Candidate folder.

So to your direct question — was there ever a properly signed, production 64-bit Windows driver for the GO7007SB? No. The closest the ecosystem ever got was that ADS Tech beta, which would run on x64 only with signature enforcement disabled. Pinnacle's PCLEUSB driver for the DVC130 fared a little better on later Windows in 32-bit mode (compatibility-mode tricks), and some users got the Plextor stack working under Windows XP Mode (virtualized) on Windows 7, but native x64 was always unofficial.

[jwillis84]

— and what you ran into with CaptureUSB is actually a pretty deep clue about why a userspace-libusb approach to the GO7007 is harder than it first looks.


What you were hitting

On USB, control transfers as a transfer type are architecturally tied to endpoint 0 (the default control pipe). The spec does allow a device to declare additional control endpoints in its descriptors, but in practice:

• Windows' USB stack (USBD/WinUSB/libusb-win32/libusbK) routes WinUsb_ControlTransfer and equivalents to EP0 unconditionally. There's no API surface for "send a SETUP packet to endpoint 2."
• The host controller hardware can do it — it's a SETUP token followed by DATA — but the OS class drivers won't issue one to a non-zero endpoint.
• libusb on Linux is the same: libusb_control_transfer goes to EP0. Period.

So if a device puts a control-typed endpoint anywhere other than 0, you basically can't reach it from userspace on Windows without writing a KMDF/WDM filter driver that crafts the URB by hand.
What the GO7007 actually does — and why it might bite you the same way
Look back at section 7.2.4 of your datasheet. The endpoint descriptors are:

• EP0 — standard control (enumeration, GetDescriptor, etc.)
• EP1 IN, bulk, 64-byte — streaming output (the compressed video)
• EP2 OUT, control, 8-byte — Interrupt Parameter + Interrupt Index registers (i.e., "send a command to the XRISC")
• EP3 OUT, bulk, 64-byte — initialization buffer (firmware download lands here)
• EP4 IN, interrupt, 4-byte, 5 ms — Interrupt Return Value + Interrupt Return Data (command results)

That EP2 is the kicker. WIS declared the command channel — the thing you'd use to configure resolution, bitrate, GOP, start/stop encoding, program the SAA7115 through the GPIO/I²C tunnel, everything — as a control endpoint at address 0x02, not as a vendor request on EP0. From the datasheet (section 7.3.3): "Endpoint #2 is used to send commands to the GO7007… the response to the OUT request will be ACK."
That is exactly the topology that breaks naive libusb code on Windows. You can't WinUsb_ControlTransfer your way to endpoint 2.

How the Linux driver gets around it


The mainline go7007-usb driver doesn't actually use EP2 the way the datasheet describes for the Plextor/ADS boxes. The Linux maintainers reverse-engineered the firmware and found that those products' firmware was patched to also accept commands via vendor-specific control requests on EP0 (bRequestType vendor, with the parameter and index packed into wValue/wIndex of the SETUP packet, exactly as USB intends). Firmware download goes to EP3 as bulk OUT, streaming comes off EP1 as bulk IN, and commands go to EP0 as vendor control — sidestepping EP2 entirely. That's why it works cleanly under libusb-style assumptions on Linux.


So the literal datasheet topology is hostile to a Windows userspace driver, but the actual topology the shipping firmware presents is friendlier — if you know what vendor request codes to use, in what order, and which firmware blob to push to EP3 first.


The escape hatch with the GO7007 is that the open-source Linux driver already worked out the EP0 vendor-request alternative, the firmware filenames (go7007fw.bin and the per-board ancillary blobs like s2250_loader.fw / s2250.fw for some variants, wis-saa7115 programming sequences for the Plextor), and the command sequencing.
So porting that knowledge — not the kernel module itself — to a libusb/WinUSB tool on Windows is tractable.


Building it blind from the datasheet would dead-end exactly the way CaptureUSB did.

[jwillis84]

The GO7007 Windows Saga: XP to Today

How USB Endpoint Conventions Drifted Between XP and Windows 7

When the GO7007SB was designed in 2002–2003, the USB 1.1 specification was the law of the land and it was genuinely permissive about endpoint typing. The spec said endpoint 0 was the default control pipe used for enumeration, but it didn't forbid a device from declaring additional control-type endpoints. Devices doing so were unusual, but they weren't violating anything. WIS's choice in the GO7007 — putting the command channel on EP2 as a control endpoint while reserving EP0 strictly for enumeration — fit the letter of USB 1.1, and the Windows XP USB stack (USBD.SYS and the WDM USB class drivers) would happily honor it provided the vendor's kernel-mode driver knew to build URBs targeted at that specific endpoint address. The Plextor and ADS Tech XP drivers did exactly that, and the device worked.
What changed between 2003 and 2009 wasn't the USB specification — USB 2.0 inherited the same language — it was the culture and the tooling. As WHQL certification got stricter, as USB-IF compliance testing got more aggressive, and as device-class specifications matured (UVC, USB Audio Class, mass storage, HID), the industry converged on a strong convention: all control traffic goes through EP0 using vendor-specific bRequest codes carried in the SETUP packet's wValue/wIndex/wLength fields. Bulk and interrupt endpoints carried data; EP0 carried commands. By the time Windows 7 shipped, every framework Microsoft offered for writing USB drivers — KMDF, WinUSB, and the libusb derivatives that sat on top of WinUSB — assumed this convention so thoroughly that the API surface for "send a control transfer to endpoint N where N ≠ 0" simply wasn't exposed. The hardware controllers can still do it (it's just a SETUP token addressed to a non-zero endpoint), but the software ladder above them was no longer built with that rung. What was unconventional in 2003 became unsupported in practice by 2009 — not through any formal deprecation, but through the steady accretion of "nobody does that anymore" in the toolchain.
The Driver Signing Wall

This collided head-on with Microsoft's introduction of mandatory kernel-mode driver signing for 64-bit Windows, which arrived with Windows Vista x64 and was enforced absolutely in Windows 7 x64. On 32-bit Windows you could ship an unsigned driver and the user would just click through a warning; on 64-bit you couldn't load an unsigned kernel driver at all without either a cross-signed certificate from a Microsoft-recognized CA or the user permanently disabling signature enforcement via boot flags. The certificate cost real money annually, the WHQL submission process cost more, and the device under test had to pass Microsoft's HCK/HLK test suite — which by then was looking for exactly the modern endpoint conventions the GO7007 didn't follow.
For a niche consumer capture box already at end-of-life, the math was hopeless. ADS Tech's 709_Vista_Candidate package was the high-water mark: an attempt by a small vendor to drag an XP-era driver forward, signed weakly or not at all, working on Vista x86 and Windows 7 x86 with a warning, and on x64 only if the user permanently disabled signature enforcement at boot. Plextor didn't even try; their official position was XP-only. Writing a new x64 kernel driver from scratch in 2010 would have required someone to (a) reverse-engineer the EP2 command protocol, (b) write a fully WDF-compliant driver that issued URBs to a non-default control endpoint, (c) get it past WHQL — which it wouldn't pass because of the non-standard endpoint usage — (d) buy a code-signing certificate anyway, and (e) sell it into a market of perhaps a few thousand stranded device owners. Nobody did it. It wasn't technically impossible; it was economically and procedurally intractable.
Why VMs and Windows XP Mode Tend to Freeze on This Device

USB passthrough into a VM looks like it should work, and for simple devices it does, but the GO7007 is unusually punishing. Three things conspire:
The chip is a USB 1.1 full-speed device plugged into a USB 2.0 or 3.0 host controller on a modern machine. The host controller talks EHCI or xHCI to the OS; full-speed devices are handled via the controller's Transaction Translator (TT) for EHCI, or via xHCI's full-speed support. The hypervisor's USB passthrough layer has to virtualize this — present a believable USB 1.1 device to the guest while actually marshaling packets through a modern host controller. Most passthrough implementations were tested heavily with mice, keyboards, and mass storage; they were not tested heavily with isochronous-adjacent bulk streaming from a full-speed device that demands microframe-accurate scheduling for audio sync. The GO7007's encoded MPEG stream comes off EP1 as bulk, but the audio travels in band and the device firmware is sensitive to host-side timing during startup.
The firmware download phase is the most fragile moment. When the device cold-starts, the XP driver downloads a multi-kilobyte firmware blob to EP3, then immediately starts an HPI command sequence against EP2 (or, for the Linux-style firmware, EP0 vendor requests), and the chip's internal XRISC has to acknowledge each step within a tight window or the boot-up state machine wedges. If the hypervisor adds even a few hundred microseconds of latency per URB — which is common with USB passthrough, especially on the first few transactions before the passthrough layer warms up — the chip's firmware times out partway through initialization and lands in an undefined state. The XP guest then sits there waiting for an interrupt on EP4 that never comes, and from the user's perspective the VM "locks up." It's actually the guest driver in an infinite wait, but because USB enumeration is happening on the critical path of device-manager I/O, the VM's UI thread blocks too.
Windows XP Mode specifically uses Virtual PC's USB stack, which was famously thin and didn't handle isochronous traffic well at all and handled bulk-streaming-from-a-full-speed-device-on-an-EHCI-host-controller poorly. Hyper-V (modern) didn't even offer USB passthrough until very late and still doesn't offer it for arbitrary devices — it offers enhanced session redirection, which is a different mechanism that won't pass a video capture device. VMware Workstation and VirtualBox both do real USB passthrough and both do better than XP Mode, but both have well-documented issues with full-speed-via-EHCI/xHCI on streaming devices. The freeze-on-driver-install symptom is almost always the firmware-download timing window described above; the freeze-on-first-capture symptom is usually the host controller dropping microframes once the device starts pushing data continuously.
The Optimal Windows XP Hardware Experience Today

Given all of the above, the most reliable setup for a Plextor PX-M402U (or any GO7007SB sibling) on Windows in 2026 is, somewhat ironically, real hardware running real Windows XP — but chosen carefully:
The ideal host is a Core 2 Duo or Core 2 Quad-era machine (roughly 2006–2009 vintage) with a chipset that has native USB 2.0 EHCI plus a companion UHCI/OHCI controller for full-speed devices — Intel ICH7, ICH8, ICH9, or ICH10 are the sweet spot. These chipsets predate xHCI entirely; full-speed USB 1.1 devices are handled by the companion UHCI controller as first-class citizens rather than being tunneled through a TT, and XP's USB stack was developed and tuned against exactly these controllers. ThinkPad T60/T61/T400/T500, Dell Latitude D630/E6400, or any small-form-factor Optiplex 755/760/780 from that era are abundant on the used market, run XP natively without driver hunting, and have the right USB silicon. Stick with 32-bit XP SP3 — the driver was written for it, signed for it, and tested on it. Give the machine a modest SSD (any SATA SSD on an ICH8/9/10 will work, though you may need to slipstream AHCI drivers or run the controller in IDE mode), 2–4 GB of RAM, and a clean install with only the Plextor driver, CapWiz, and whatever editor you'll use downstream. Keep it offline or behind a firewall — XP hasn't had security updates in over a decade.
This avoids every problem at once: no signing issues because the driver matches the OS era it was written for, no USB timing issues because the host controller is the kind the firmware was developed against, no hypervisor in the loop adding latency to the firmware-download handshake, and no x64 driver model to fight. The hardware costs $30–80 on eBay, and the resulting setup will capture as reliably in 2026 as it did in 2006.
If buying old hardware feels wrong, the second-best option remains a Linux box with the mainline go7007 driver and ffmpeg — that path bypasses the entire Windows driver question and was, in retrospect, always the cleanest answer. But if "I need this to work under Windows with CapWiz or with the original Plextor capture app," then a period-correct XP machine on period-correct silicon is genuinely the right tool, and it will outperform any VM-based attempt by a wide margin.

[jwillis84]

A more advanced hospice scenario is pair the device with a Raspberry Pi that runs ffmpeg against the linux device using the mainline go7007 device driver, serve up the stream as a udp:// endpoint on a local network and ingest that with OBS Studio on your windows machine and transcode to your hearts content.. probably MP4 stored in a MKV file.

That's worked for me with almost all of these old devices now .. but the above story explains it the way I wish I didn't have to learn it over the last 20 years.

[OS_Man]

Thanks everyone for the detailed explanations so far, especially the comments about WinDVD Creator relying on how the hardware encoder presents the stream and the importance of driver/DirectShow behavior.

To clarify my situation a bit better:

I actually have access to period-correct hardware from that era (early 2000s components), including compatible motherboard, CPU, RAM, HDD, and USB 2.0 chipset options. So my idea is not to run Windows XP on a modern PC, but to build a fully native XP-era system if that turns out to be the most reliable approach.

Given that, I wanted to ask:

Would a fully period-accurate setup (XP SP2 + original Plextor drivers + WinDVD Creator 2 + matching chipset hardware) significantly increase the chance of the PX-M402U working properly compared to trying to fix it on newer systems like Windows 7?

Or are there still known issues even on fully native XP-era hardware that would make this device unreliable regardless of the environment?

I’ve also seen alternative software mentioned (NeroVision, Ulead, etc.), but it’s not clear whether the issue here is software-specific or more fundamentally tied to how this device exposes its video stream.

If anyone has experience with a known working hardware + OS + software combination, I’d really appreciate the details.

[lojelo5]

I have this device still, but one major issue with it Plextor released a firmware for it that stopped windvd creator2 from crashing and also helped with other software. I tried to search for it for many years I even messaged Plextor they didn't have it on their servers anymore so it is now sitting in a box in the loft because it is pretty useless without this firmware.

This was the last firmware I had for it but they released a final one a bit later.

M402U_2305c

By the way it best worked in XP service pack 1/2 only