[Windows] Connection problems with Enttec OpenDMX USB Interface

[alessandrocaseti]

Describe the bug
QLC has some issues in connecting my Enttec OpenDMX USB interface. If the device is plugged in, QLC won't start at all. If disconnected, it will start but as soon as I plug the cable in it immediatly crashes. This only happens in version >= 4.13.0. I haven't tried on V5 but since it isn't stable I can't use it for my current projects. I tried 4.12.7 and had no issues at all.

To Reproduce
Steps to reproduce the behavior:

1. Insert Enttec OpenDMX USB interface
2. Open QLC Version >= 4.13.0
3. Disconnect Enttec OpenDMX USB interface
4. Re-open QLC and plug in the cable again

Temporary solution
From the forum, I found a temporary solution:

1. Open Device Managment
2. Disable and re-enable the device under USB Controllers
3. Quickly open QLC

Desktop (please complete the following information):

• OS: Windows 11 Version 23H2
• QLC+ Version 4.13.1

Additional context
This bug has been reported from other users and additional context can be found here:
https://www.qlcplus.org/forum/viewtopic.php?t=17163
https://www.qlcplus.org/forum/viewtopic.php?t=17960
https://www.qlcplus.org/forum/viewtopic.php?t=17370
https://www.qlcplus.org/forum/viewtopic.php?t=18044

[mcallegari]

What we know about this so far:

• Happens only on Windows
• Doesn't happen on every Windows machine
• Doesn't happen at every startup
• QLC+ 4.13.0 and higher has switched to a 64bit build. Compared to 32bit, one file needed to be added to the deploy: ftd2xx64.dll
• Some users fixed the issue by installing the FTDI driver from ENTTEC and removing duplicate DLL (this post)
• the installed DLL comes from the official D2XX package version v2.12.36.4
• I am personally not able to reproduce the crash. All the Windows instances that I tested worked out of the box (even PCs that never saw QLC+ before)

[alessandrocaseti]

@mcallegari any news on this? Is there any chance that this issue is related to #1656 ?

[mcallegari]

@mcallegari any news on this? Is there any chance that this issue is related to #1656 ?

No

[leonreucher]

Same issue here - tried on two Win 11 machines, driver was reinstalled several times - but with the interface connected, QLC won't start. When the interface is connected after the program start, the software crashes.

[mcallegari]

We involved ENTTEC and they cannot reproduce the issue either on two Windows 11 machines.

[alessandrocaseti]

@mcallegari the weird thing is that, in my case, it started to happen only in december. Before than, i used another open-DMX interface (worked without any issues), that got killed by a voltage surge. When trying the new one, it worked well but only for 1 time. The second time opening it it started giving issues (the PC is alsways the same). Is there any log file that I can share when I try to open the app with the interface connected?

[mcallegari]

@alessandrocaseti can you please confirm if you are using an original Enttec Open DMX or a clone?
There's a lot of fake FTDI chips on the market and I suspect the driver rejects them with unexpected outcomes.

[alessandrocaseti]

@alessandrocaseti can you please confirm if you are using an original Enttec Open DMX or a clone?
There's a lot of fake FTDI chips on the market and I suspect the driver rejects them with unexpected outcomes.

Yes, i confirm. The interface is undoubtedly original.

[acotam2]

Windows 11 24H2 x64, QLC+ 4.14.0, CDM212364 driver from FTDI Website, both fake and real FTDI chip based adapters, cannot reproduce
same with windows 7 SP1 x64, QLC+ 4.13.1, same drivers, same adapters, also cannot reproduce.

BTW drivers from enttec website are identical to CDM212364 from FTDI website, checksums of files used are identical: ftd2xx64.dll, ftser2k.lib, ftcserco.dll, ftserui2.dll checked.

[alessandrocaseti]

don't know if this can be helpful, but i've recently changed the disk on the PC that has this problem from a HD to an SSD and I still get this issue (did a clean windows 11 install via USB, i didn't clone the old disk).

[CarlosAg]

I'm running into the same issue when using Enttec OpenDMX, and it has been working great for the last 3 years until some time a couple of months ago, and it seems to be an AV on ftd2xx64!FT_GetQueueStatus, dmxusb!qt_plugin_instance. I tried installing also qLC 4.14.0 and it did not solve the issue. (I use Windows 10 Version 22H2 19045.5608)

0:000> kb

RetAddr : Args to Child : Call Site

00 00007ffa7dc06fd5 : 0000000000000000 0000027fd80eef30 0000027fd80e4b50 00007ffa7dc00942 : ftd2xx64!FT_GetQueueStatus+0xcac6 01 00007ffa7dbfca51 : 0000000000000000 000000b0e35ff6c8 0000000000000000 0000027fd80e4b50 : ftd2xx64!FT_GetQueueStatus+0x12cc2
02 00007ffa8425e4ee : 000000b0e35ff440 000000b0e35ff0a0 000000b0e35fed10 000000b0e35fed10 : ftd2xx64!FT_GetQueueStatus+0x873e 03 00007ffa8424b017 : 000000b0e35ff460 0000027fd8230000 0000027fd8230000 00007ffb08475cc1 : dmxusb!qt_plugin_instance+0x2c88e
04 00007ffa8423db33 : 0000027fdae0ecd0 01007ffb00000002 0000000000000007 00007ffa8426afd0 : dmxusb!qt_plugin_instance+0x193b7 05 00007ffa8de9fda4 : 000000b0e35ff890 0000027fdad27080 0000027fdad27080 0000000000000001 : dmxusb!qt_plugin_instance+0xbed3
06 00007ffa8d4383be : 0000027fd8294a80 000000b0e35ff890 00007ffa8755a6f0 00007ffa87401980 : qlcplusengine!ZN13IOPluginCache4loadERK4QDir+0x804 07 00007ffa8d43e508 : 00007ffa8d6c83ef 0000000000003960 0000000000003960 0000027fd8277da0 : qlcplusui!ZN3App7initDocEv+0x1de
08 00007ffa8d43f01f : 0000000000000000 0000027fd8230000 0000000000000017 00007ffa8d6c83ef : qlcplusui!ZN3App4initEv+0x3c8 09 00007ff7bfd1280a : 0000000000000014 0000000000000020 0000000000000000 000000b0e35ffb24 : qlcplusui!ZN3App7startupEv+0xf
0a 00007ff7bfd1462c : 0000000000000001 0000000000000020 0000000000000068 0000027fd808cf00 : qlcplus+0x280a 0b 00007ff7bfd11319 : 0000000000000000 0000000000000014 00007ff7bfd220c8 0000000000000000 : qlcplus+0x462c
0c 00007ff7bfd11406 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : qlcplus!__tmainCRTStartup+0x169 [C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 267] 0d 00007ffb074c7374 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : qlcplus!WinMainCRTStartup+0x16 [C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c @ 157]
0e 00007ffb0849cc91 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : KERNEL32!BaseThreadInitThunk+0x14 0f 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x21

0:000> lmDvmdmxusb
Browse full module list
start end module name
00007ffa84230000 00007ffa84296000 dmxusb (service symbols: DWARF Private Symbols) C:\QLC+\Plugins\dmxusb.dll
Loaded symbol image file: C:\QLC+\Plugins\dmxusb.dll
Mapped memory image file: C:\QLC+\Plugins\dmxusb.dll
Image path: C:\QLC+\Plugins\dmxusb.dll
Image name: dmxusb.dll
Browse all global symbols functions data Symbol Reload
Timestamp: Wed Jan 15 12:33:12 2025 (67881B88)
CheckSum: 00093B84
ImageSize: 00066000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

0:000> !lmi ftd2xx64
Loaded Module Info: [ftd2xx64]
Module: ftd2xx64
Base Address: 00007ffa7de10000
Image Name: C:\QLC+\ftd2xx64.dll
Machine Type: 34404 (X64)
Time Stamp: 60e2fd3b Mon Jul 5 05:38:19 2021
Size: a3000
CheckSum: a2704
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 62, 88ab0, 878b0 RSDS - GUID: {BF639ECA-DB1B-4796-80D3-7F2FE5056AD2}
Age: 1, Pdb: c:\Jenkins2\workspace\J171-Windows-D2XX-VCP-VS2015\x64\Release\FTD2XX.pdb
VC_FEATURE 14, 88b14, 87914 [Data not mapped]
Image Type: FILE - Image read successfully from debugger.
C:\QLC+\ftd2xx64.dll
Symbol Type: EXPORT - PDB not found
Load Report: export symbols

0:000> g
(35b4.1f8c): Access violation - code c0000005 (!!! second chance !!!)
ftd2xx64!FT_GetQueueStatus+0xcac6:
00007ffa7de20dd9 0fb7440a2c movzx eax,word ptr [rdx+rcx+2Ch] ds:00000192c73c2c61=????

I've tried installing the latest drivers I found in the Enttec site below, but does not seem to solve the problem:
https://www.enttec.com/product/dmx-usb-interfaces/open-dmx-usb/

Also tried the newer ones here: https://ftdichip.com/drivers/d2xx-drivers/
2.12.36.20

Are there private pdb symbols, I'm happy to help debug if useful.
Please help, this really is blocking us from using QLC on our band, and have had to use sound only mode on our lights.

[yestalgia]

Can we get some PC specs/model numbers for the machines you guys are having issues with? I'd be interested in trying to correlate the data to find common factors.

As stated by Massimo, ENTTEC wants to help us with this but is currently unable to reproduce the problem.

[CarlosAg]

Mine is an Enttec Open DMX USB PN: 70303, 2352687.
I have been using it in a Windows 10 Laptop HP Spectre x360 for three years without any problems:
Windows 10 Home
Version: 10.0.19045 Build 19045
HP Spectre x360 Convertible
Intel i7-7500U CPU, 2.70 GHz, 2 Cores, 4 Logical Processors.
RAM: 12 Gb

and I just connected the same Enttec Open DMX to my Win11 Desktop and get the same AV's:
Windows 11 Pro
Version: 10.0.26100 Build 26100
Dell XPS 8960
Intel i7-14700, 2100 Mhz, 20 Cores, 28 Logical Processors.
RAM: 32 Gb
I installed the latest drivers FTDI 10/28/2024 - 2.12.36.20 that is used by the USB Serial Port (COM3).

For what is worth, the AV happens when calling FT_EE_Read at line 58 plugins\dmxusb\src\ftd2xx-interface.cpp, but it is hard to say more given there are no symbols for that (I built it locally so I could get the symbols and debug the source, but that is as far as symbols go).

static FT_STATUS get_interface_info(DWORD deviceIndex,
...
pData.SerialNumber = cSerial;
status = FT_EE_Read(handle, &pData);
if (status == FT_OK)
...

It seems that eventually it happens in ftd2xx64!FT_GetQueueStatus.

FWIW, I downloaded the Enttec c# sample and it seems to work turning on the lights connected to it, is able to FT_OPEN it correctly (same as QLC), and then uses FT_SetBreakOn/Off and FT_WRITE all good.

Happy to help troubleshoot whatever else is needed (let me know if more specs are useful, though given I've seen the same device misbehave on completely different machines with different Windows and all, I suspect it is more about the device and maybe the chip used).

[alessandrocaseti]

potential fix found on the forum

https://www.qlcplus.org/forum/viewtopic.php?p=76948#p76948

seems to be an issue related to the serial number ??

[CarlosAg]

I am working around this issue for now while the real fix is found by running my own build of QLC and commenting out the call to FT_EE_READ and I am just hardcoding my device info that I got by writing a quick program using FT_CreateDeviceInfoList and FT_GetDeviceInfoList.

vendor = QString("FTDI");
description = QString("FT232R USB UART");
serial = QString("AB0PVMFM");
VID = DMXInterface::FTDIVID;
PID = DMXInterface::FTDIPID;

One thing I noticed is that in the past very commonly it would show in the Input/Output an empty S/N, but now that is hard coded it shows it well, so I guess the device might be inconsistent in returning the data.

[mcallegari]

@CarlosAg thanks for the analysis.
According to the official documentation, we might try to adjust the buffer sizes to the exact length. I would also memset them to 0 for safety.
This is their reference code:

FT_PROGRAM_DATA ftData;
char ManufacturerBuf[32];
char ManufacturerIdBuf[16];
char DescriptionBuf[64];
char SerialNumberBuf[16];

ftData.Signature1 = 0x00000000;
ftData.Signature2 = 0xffffffff;
ftData.Version = 0x00000005; // EEPROM structure with FT232H extensions
ftData.Manufacturer = ManufacturerBuf;
ftData.ManufacturerId = ManufacturerIdBuf;
ftData.Description = DescriptionBuf;
ftData.SerialNumber = SerialNumberBuf;

ftStatus = FT_EE_Read(ftHandle, &ftData);

I'm not sure if this can help, but not being able to reproduce the crash I need to ask @CarlosAg to test it for us.
If it still crashes, it means we have an issue with EEPROMs mounted (or not?) on the PCB, which might be really hard to detect.
We might ask ENTTEC about this.

[CarlosAg]

I should have posted that I tried those suggested above back then and all permutations I could think of such as using those sizes recommended in the PDF at their side, changing those a bit, memset..., also changing the version from 0-9, and none of the changes worked. I even wrote a separate simple c++ app that was just calling the FT_EE_READ to be able to test those changes quickly and nothing worked, it would 'randomly' (say 80% of the time) AV. I also wrote a C# sample using pinvoke and passing larger/smaller buffers... and similarly it would work 1 out of 10 times or so (and AV in the others, which is really hard since you can't handle that exception and process just dies).

As others have highlighted, if I "spam-launch" QLC quickly... a few of those instances will AV and a very small count will not AV and those that start it will work (which I think correlates to the failure rate I see above, so launch 10 times, chances are 1 or 2 will start... funny sometimes you end up with multiple QLCs but just close all but one).

I do suspect there is something with the device itself and needs EntTec help (either some timing... or firmware, or something in the EEPROM).
Do you have a contact with ENTTEC that would be willing to engage? I am happy to connect with them and try to help debug since I have the device that is trivial to reproduce.

I will play with this more over the weekend, and try again to see if I did not make a mistake on my attempts before, but I'm 99% sure I tried all of those correctly

[CarlosAg]

I can confirm that it AV's and it seems to happen right after finishing reading the serial number:

These is the memory address for the four char[] 
FTDI............................
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
AB..............ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌFT232R U
SB UART.........................
........................ÌÌÌÌÌÌÌÌ
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌAB0PVMFM........
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ

`

<title>Document</title>

	Name	Value	Type
◢	ftData	{Signature1=0 Signature2=4294967295 Version=5 ...}	ft_program_data
	Signature1	0	unsigned long
	Signature2	4294967295	unsigned long
	Version	5	unsigned long
	VendorId	1027	unsigned short
	ProductId	24577	unsigned short
	▶ Manufacturer	0x000000ab4b2ff598 "FTDI"	char *
	▶ ManufacturerId	0x000000ab4b2ff5d8 "AB"	char *
	▶ Description	0x000000ab4b2ff610 "FT232R USB UART"	char *
	▶ SerialNumber	0x000000ab4b2ff668 "AB0PVMFM"	char *
	MaxPower	90	unsigned short
	PnP	0	unsigned short
	SelfPowered	0	unsigned short
	RemoteWakeup	0	unsigned short

with everything else being '\0'

`

[alessandrocaseti]

@mcallegari hi, do we have any news on this? It's a problem related to QLC, the drivers or a faulty Enttec interface? If so, has Enttec been involved? Thanks.

[yestalgia]

@mcallegari hi, do we have any news on this? It's a problem related to QLC, the drivers or a faulty Enttec interface? If so, has Enttec been involved? Thanks.

I've just emailed Enttec and will be giving one of the engineers a call tomorrow to follow up.

Hopefully we can crack this issue with their help.

[ClarkLiam]

Hey guys, I don’t want to open a new issue but I was am also experiencing the same issue on my main lighting PC. When trying to connect the Interface, it shows up (Name + S/N), but then does not output anything. If you then try to click it and configure the interface, the config window pops up, but only shows an empty, nameless device without S/N. Interestingly enough this only seems to be happening on the main PC. The identical Interface connects to my MacBook just fine, we are experiencing some flickering of the Lights (note: could also be a problem with the in house DMX wires and splitter).

[yestalgia]

Enttec's key engineer is currently on leave...

Great timing but I'll keep you all updated.

[shaforostoff]

I tried reproducing this using windows 23H2 running thinkpad t14. qlc 4.14.1.

T232R USB UART (S/N: B002N96D)
Device is operating correctly.
Driver in use: FTD2xx
Protocol: Open DMX USB
Manufacturer: FTDI
DMX Channels: 512
DMX Frame Frequency: 30Hz
System Timer Accuracy: Bad

Tried plugging and unplugging usb white QLC was running and vice versa.
Tried enabling usb hotplugging (plus restart like the tooltip says), but nevertheless I always had to restart the QLC+ after replugging.

Still I got no crash.

[vheat]

Same issue here, Windows 11, PC is a 3 year old NUC, ENTTEC USB DMX PRO. exact versions I currently have not available. Last year we used same machine with a genuine FTDI 232R + RS485 interface to control the same DMX setup, there we had no trouble except some flickering due to loaded PC and not buffering interface, so we changed to buffering USB DMX PRO.
Now we see the effect that after some random time the USB DMX PRO does not to look to receive changes from QLC+, the green LED on the USB DMX PRO stays off continously, DMX buffering takes care of repetion, so we are not in the dark.
In some cases we couldn't press/slide QLC+ anymore, in some cases it was still possible (with no new data sent to the USB DMX PRO). Up to this point QLC+ starts up and works completely perfect. While the hang, we had no crashes, sometimes QLC+ became unresponsive when stopping it.

My few cents on this, FTDI has trouble with fakes, they may have checks in the driver which check for (format of) valid serial numbers, these checks may be sprayed in the driver and not always active. There are lists available on Internet, how fake serial numbers look. As a result using fake chips would give random hickups, at the end they become unusable for critical applications as operation is not stable.
When I compare my old simple adapter, it shows a serial number like AQ00AB77. The ENTTEC USB DMX PRO shows like EN123456. (These number are reported by QLC+). I have to check the FTDI service tool whether the length holds when reading NVM out of the FTDI232R.
Following what is reported in mentioned forum posts, I'll try to update the serial number to my known one and see whether the issue persists to us. I see a good chance to work.
Wonder whether there exist older ENTTEC adapters which do not show an EN=ENTTEC serial number but an FTDI one like AQ....

It is understood that FTDI has a business reason to sort out fake chips and to take appropriate measures on fakes. Beside involving ENTTEC, FTDI should get involved as well to check whether such checks may exist in the FTDI drivers for Windows.

[Z00rginal]

I was directed here from the QLC-forum. I have the same problem with not being able to start any version of QLC+ 4 later than 4.12.7. I have a Dore-midi USB-DMX-cable. If I unplug the cable QLC starts. QLC actually have started a couple of times with the cable inserted, it seems to detect the cable but doesnt output anything (the "out"-led on the cable isnt lit and my dmx-lights wont turn on).
4.12.7 works fine and it identifies my cable as FT232R Uart (s/n: AB0KT9HX) with driver FTD2xx. Cable-led out is lit and I can control my DMX-lights. I have the same behaviour on two different computers, one old latitude e7250 and one new stationary, both running windows 11. I havent downloaded any specific driver, the one Windows seem to be using is FTDI 2.12.36.4.

I dont know how to see if its a genuin FTDI-chip (dont know what that means really), here is the output from microsoft usb-view, sorry if its just spam, It seems like a great prog and perhaps someone smarter than me sees a clue...
Good luck!

Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 (8)
idVendor: 0x0403 (Future Technology Devices International Limited)
idProduct: 0x6001
bcdDevice: 0x0600
iManufacturer: 0x01
0x0409: "FTDI"
iProduct: 0x02
0x0409: "FT232R USB UART"
0x0409: "FT232R USB UART"
iSerialNumber: 0x03
0x0409: "AB0KT9HX"
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x0B
Open Pipes: 2

Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x01

Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x01

Configuration Descriptor:
wTotalLength: 0x0020
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xA0 (Bus Powered Remote Wakeup)
MaxPower: 0x32 (100 Ma)

Interface Descriptor:
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF
bInterfaceSubClass: 0xFF
bInterfaceProtocol: 0xFF
iInterface: 0x02
0x0409: "FT232R USB UART"
0x0409: "FT232R USB UART"

Endpoint Descriptor:
bEndpointAddress: 0x81 IN
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x01

Endpoint Descriptor:
bEndpointAddress: 0x02 OUT
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x01

[shaforostoff]

• QLC+ 4.13.0 and higher has switched to a 64bit build. Compared to 32bit, one file needed to be added to the deploy: ftd2xx64.dll
  Does this mean that shipping 32-bit version in addition to 64-bit will solve this problem?

[mcallegari]

Building a 32bit version is no longer an option.
MSYS2 is no longer providing 32bit builds of Qt and they are removing old packages.
Official Qt versions are not providing 32bit builds anymore

[yestalgia]

Hey all, another update on this one. >_<

We've contacted FTDI directly as we don't currently have the ability to reproduce this issue. Hopefully they respond to our emails. Failing this, we might have to put a bug bounty up for it 🤷.

ENTTEC are still trying to reproduce the issue but are thus far unsuccessful.

Super weird problem - I hope progress is made soon. The moment we hear anything we'll share details here.

[vheat]

Will enabling the logging in QLC+ change the direction of investigation? -d 0 --log 2>c:\log.txt
Would we see whether QLC continues to send data or break? Would a Wireshark on USB help?

[mcallegari]

@vheat no. The issue has already been perfectly analyzed by @CarlosAg and is not in the QLC+ code.
That's why we are involving who can actually explain this behaviour and help resolve it.

@ALL Unless you can provide an actual fix or workaround, please wait for our updates here as already stated by @yestalgia. Let's keep this discussion clear and useful.

[shaforostoff]

I am working around this issue for now while the real fix is found by running my own build of QLC and commenting out the call to FT_EE_READ and I am just hardcoding my device info that I got by writing a quick program using FT_CreateDeviceInfoList and FT_GetDeviceInfoList.

If we don't find a proper fix, I suggest this workaround: have a separate minimal c++ program reading serial number and other data shipped with QLC+. Before QLC+ tries to read this data itself, it creates and empty file somewhere. After read succeeds, this file is deleted. If crash happens, QLC+ will detect this empty file on the next start and will know that it should invoke a separate program for reading serial number and other data, and do that. This separate program would then put this info into that empty file.

What do you think?

[CarlosAg]

Will enabling the logging in QLC+ change the direction of investigation? -d 0 --log 2>c:\log.txt Would we see whether QLC continues to send data or break? Would a Wireshark on USB help?

Unfortunately no logging will catch this since it is an AV (memory access violation) the operating system terminates immediately the process.

If anyone is blocked and desperate and wants to try my hack/workaround ping me and I can share that dll (just a single .dll needs to be replaced on the plugins folder which you should backup and can restore original if needed easily). I have used it in a few shows now and it has worked well in my context with single Enttec open. (Again, this is a workaround and the issue is NOT in QLC and is a hack to workaround the call to FT_EE_READ )

[alessandrocaseti]

Will enabling the logging in QLC+ change the direction of investigation? -d 0 --log 2>c:\log.txt Would we see whether QLC continues to send data or break? Would a Wireshark on USB help?

Unfortunately no logging will catch this since it is an AV (memory access violation) the operating system terminates immediately the process.

If anyone is blocked and desperate and wants to try my hack/workaround ping me and I can share that dll (just a single .dll needs to be replaced on the plugins folder which you should backup and can restore original if needed easily). I have used it in a few shows now and it has worked well in my context with single Enttec open. (Again, this is a workaround and the issue is NOT in QLC and is a hack to workaround the call to FT_EE_READ )

yes please, could you share that dll somewhere? I'm gonna try this fix later this week.

[mcallegari]

FTDI has replied.
Basically there is a bit of confusion on the 32/64 bit DLL naming. They are both in C:\Windows\System32 under the name FTD2XX.DLL.
They suggest to replace one copy (either Windows' one or QLC+ one)
!!MAKE A BACKUP COPY FIRST!!

Case 1) Copy C:\Windows\System32\FTD2XX.DLL to the QLC+ folder. Then rename it to ftd2xx64.dll
Case 2) Copy ftd2xx64.dll from the QLC+ folder to the Windows System32 folder and rename it to FTD2XX.DLL

Hopefully case 1 will solve the issue but not being able to reproduce I need you to test for me and report back here. Thanks

[alessandrocaseti]

@mcallegari Thanks for involving FTDI. I'm gonna test this fix later this week.

[Z00rginal]

Hi!
I tried solution Case1 and Case2 but unfortunately the problem remains. As soon as I unplug my doremidi-cable I can start the program without problem. Simply removing ftd2xx64.dll from QLC folder allows the program to start but it doesnt detect the doremidi-cable (probably obvious).
Im on a new windows 11 PC.
Best of luck,
Johan

[alessandrocaseti]

unfortunately, those solutions don't work for me either. Tried both methods with no results. The problems persists

[CarlosAg]

Similarly, I tried both proposed solutions and the crash still happens all the same.

[yestalgia]

Is it possible that the change in DLL requires a restart of Windows in addition to perhaps plugging in/unplugging of the device?

Thanks again everyone for your help with this.

[alessandrocaseti]

Is it possible that the change in DLL requires a restart of Windows in addition to perhaps plugging in/unplugging of the device?

Thanks again everyone for your help with this.

yesterday I restarted my system several times and still got nothing. I've now noticed that in the /System32 folder there are two DLLs. One named ftd2xx and another one ftd2xx64. May those two be in conflict with each other?

[Z00rginal]

On my machine theres only ftd2xx in the /System32 folder, theres a ftd2xx and ftd2xx64 in a much "deeper" folder C:\Windows\System32\DriverStore\FileRepository\ftdibus.inf_amd64_27ad3b85ed46c2a0\i386
This seems more like a storage-place for drivers when you need them, unlikely they should interfere?
In my case the QLC+ v5 works, is that irrelevant? Or is v5 also using the 64bit driver that you switched to with v 4.13?
Take care!

[alessandrocaseti]

@Z00rginal You're saying that you have both of them under \i386? in my case, under \ftdibus.inf_amd64_27ad3b85ed46c2a0\i386 there's only ft2xx.dll, the 64 bit version is under \ftdibus.inf[...]\amd64.

Apart from QLC5, the enttec interface works without problems with 4.12.7, which is the version that i'm forced to use. Also, yesterday I've tried putting a €20 dmx-usb adaptor from amazon that is not from enttec and works perfectly even on 4.14.1-2 🤷‍♀️

[Z00rginal]

Hi, you are right, I have ftd2xx.dll in the \386 folder and ftd2xx64.dll in the \amd64 folder.
Would you mind telling which amazon-adaptor you got? Just in case...

[alessandrocaseti]

Hi, you are right, I have ftd2xx.dll in the \386 folder and ftd2xx64.dll in the \amd64 folder. Would you mind telling which amazon-adaptor you got? Just in case...

It's a simple dmx-usb adaptor I found on amazon for 20 bucks from "dsd". It was the cheapest I could find. It works perfectly in the smallest room of the venue where I work, which has 6 washes and 2 pars (around 80 channels). But, it has some flickering issues if used in the bigger room (around 400 channels - originally controlled by the Enttec interface). That is totally understandable for me, lower cost means lower applications, but the strange fact is that it is recognized instantly and starts transmitting without issues, when the original enttec interface has the problems that all of us reported in this conversation.

[vheat]

On two systems I tested the ftdi libs. Not by copying just by comparing them with Windows command "fc /B" . On both systems the libs were binary equal. Looking at the properties in Win Explorer showed same release date/signing for both. From this I assume copying wouldn't change anything, so reason for FTDI advise should be clarified if both are binary equal.
I did another test looking for "listdlls" from sysinternals, which shows all active libraries in a system. When QLC was up, I saw only the one lib from QLC directory, The system32 lib was not loaded by any other program. If we expect a conflict between the libs concerning shared resources, it may be worth to check using listdlls, whether both libs are active. As we know, not all systems are affected, so there may be another tool on the affected systems which refers to system32 lib and causes the conflict on resources.

[mcallegari]

Please try the attached DMX USB plugin. Replace the one in the Plugins folder and let me know if QLC+ starts correctly and if so, if the device data are correct (SN, name, etc)

dmxusb.zip

[alessandrocaseti]

Thank you Massimo, i'm going to test it tomorrow.

[alessandrocaseti]

@mcallegari now QLC starts but is unable to send data via the device. The DMX-USB entry is no longer available in the output plugins list. The interface is correctly plugged in and still recognized by 4.12.7.

I've now tried to replace the dll you sent me with the old one, and qlc does not start if the adaptor is plugged. Unplugging it allows QLC to start and the plugin is correctly listed in the output tab.

[mcallegari]

Ok, sorry, you need the whole package
Please try this one
qlcplus-20250424-DMXUSB-patch.zip

[supergigi59]

Thanks Massimo,
I tried with my eurolite usb-dmx512-pro MK2 and now it works. The serial number is displayed and the interface seems to work correctly.

[mcallegari]

Good news! If I have the confirmation from other people here then I'll commit the changes.
Basically, thanks to a hint FTDI gave me, I used another API (FT_ReadEE instead of FT_EE_Read) that doesn't crash even if the device is fake or the EEPROM is unreadaable.

[alessandrocaseti]

@mcallegari IT WORKS! Thank you so much! Device recognized successfully. Serial number is correct. The hardware works as espected. 2 observations:

• Before lanching the patched version, Windows asked me to confirm if I wanted to run the application as it was not "recognized" by Windows Defender SmartScreen.
• First startup took approximately 1 minute on my machine. After the first one, it now takes less than 2 seconds.

But i'm very confident that I've encountered these issues because i've installed a GIT version of the app.

Thank you again! This issue got me crazy in the past months. Can't wait for the official 4.14.2 release!

[Z00rginal]

Yes, your fix seems to work, QLC+_4.14.1-2 starts fine with my doremidi cable plugged in and the serial number is showing in the inputs/outputs.
Great work, I´m buying myself a QLC+ laptop sleeve!

[alessandrocaseti]

@mcallegari Sorry for continuing the conversation, but I wanted to report some issues i've experienced yesterday during my first show made with version 4.14.2 GIT.

• webaccess does not load some images (e. g. button background images)
• fixture monitor no longer reflects the outputted dmx values (even if the fixtures are fixed it still show an EFX running)
• RGB matrices cannot be disabled. (I have a couple FXs and a RGB matrix in a solo frame - if enabling the RGB matrix and switching to a FX, those 2 cues will mix together!) To disable the matrix you need to hit the disable all functions button.

Again, sorry for reporting those issues here, but I wanted to tell about them so you could at least check if you encounter those problems.