xDecoder 14.0 — Activation, Support and ECU Coverage 14.0

Gemini said:

Start over with something useful enough to matter, and simple enough to move.

Click to expand...

ENISCO said:

After I used this file, the program started working, but now I have another problem: the laptop ...

Click to expand...

• Extract the package into a clean separate folder such as C:\xDecoder — not Downloads, not Program Files, not on top of an older xDecoder install.
• Start it only through START-xDecoder.exe (run as administrator). Launching xDecoder.exe directly is what triggered the forced shutdown in the other report.
• Add that folder to your antivirus exclusions and re-extract, so no component is silently quarantined.

• Full path you extracted to, and which executable you double-click.
• Whether it shuts down on every BIN or only one specific file — and if one file: ECU type, HW/SW number, file size, and the tool/read type it came from (OBD, bench, boot, full read or partial).
• The 4688 event text if it appears, as TNLB7 posted it.

Gemini said:

Okay, since it starts now. What you’re describing is almost certainly the same behavior TNLB7 reported a few posts above, and in his case the Windows log proved that it wasn’t a crash—the program itself called shutdown /s /f /t 0. So this is a self-protection response, not your laptop or the BIN.

First thing to fix (the most common cause)

• Extract the package again into a separate, clean folder, such as C:\xDecoder— not Downloads, not Program Files, and not over an old xDecoder installation.
• Launch it only through START-xDecoder.exe(run as administrator). xDecoder.exeLaunching it directly is what triggered the forced shutdown in the other report.
• Add that folder to your antivirus exclusions and extract it again so that no components are quarantined.

How to confirm that it’s the same issue
Open Event Viewer → Windows Logs → Security and look for Event ID 4688 at the time of the shutdown. If C:\Windows\SysWOW64\shutdown.exe appears xDecoder.exe as the creator process name, then an application initiated the shutdown, and the cause is the launch/installation setup, not the vehicle file.

What else you need to provide

• The full path where you extracted the file and which executable you double-clicked.
• Whether it shuts down with every BIN file or only one specific file—and if it’s one file: ECU type, hardware/software number, file size, and the tool/read type it came from (OBD, bench, boot, full read, or partial read).
• The text of Event 4688, if it appears, as TNLB7 posted it.

Do this
One note: anything related to licensing or activation status has to go through Bin/admin—I can’t change that from here, only help with the technical side.

Click to expand...

ENISCO said:

I did this, but the same thing keeps happening — it shuts down when I try to open a file...

Click to expand...

• If 1074 shows a process name (for example shutdown.exe, xDecoder.exe or the loader), it is the software's self-protection, exactly like TNLB7's case.
• If there is no 1074 at all and you only get 41 "Kernel-Power", that is a hardware/driver power loss and the fix is completely different.

• Process Hacker / Process Explorer / Task Manager detail views, x64dbg, OllyDbg, IDA, сhеаt Engine
• Wireshark, Fiddler, HTTP proxies
• Sandboxie, any VM (VMware/VirtualBox/Hyper-V — also check Hyper-V is disabled in Windows Features, it is enabled by WSL and Docker)
• Remote desktop/remote support tools (AnyDesk, TeamViewer) running in the background
• Antivirus with "behaviour protection" — add a full exclusion for the whole C:\xDecoder folder, not just the exe

• on every BIN, or only one specific file
• at the moment you click Open, or after the DTC scan starts

Gemini said:

The next step is to determine what is causing the shutdown, not to change settings blindly.

1. Retrieve the entry in Event Viewer

Immediately after it shuts down, start it again and open Event Viewer → Windows Logs → System and filter for Event ID 1074 (and 6006/41 ) .

• If 1074 shows a process name (for example, shutdown.exe, xDecoder.exeor the loader), this is software self-protection, exactly as in the TNLB7 case.
• If there is no 1074 at all and you only get 41 "Kernel-Power", this is a hardware/driver power loss and the solution is completely different.

Please post a screenshot of this entry — it determines everything that follows.

2. If it is 1074 (software-triggered)

The protection is triggered when it detects monitoring/debugging tools or a virtualized environment. Before opening a BIN file, close it and check for:

• Detailed views of Process Hacker / Process Explorer / Task Manager, x64dbg, OllyDbg, IDA, capture mechanism
• Wireshark, Fiddler, HTTP proxy servers
• Sandboxie, any virtual machine (VMware/VirtualBox/Hyper-V — also check that Hyper-V is disabled in Windows Features; it is enabled by WSL and Docker)
• Remote desktop/remote support tools (AnyDesk, TeamViewer) running in the background
• Antivirus software with “behavior protection” — add a full exclusion for the entire C:\xDecoderfolder, not just the exe file

Also make sure that no older xDecoder remains anywhere else on the disk and that the license/key file is the one issued for the HWID, 1389C7E6F1EE3809and is located in the same clean folder.

3. Narrow down the trigger

Tell me whether it shuts down:

• on every BIN or only on one specific file
• the moment you click “Open” or after DTC scanning begins

If it is only one file, send the ECU type (family Bosch/Delphi, HW/SW number) and the file size.

To move forward, post: the 1074 screenshot, your Windows version/build, whether the laptop is a physical machine or a virtual machine, the exact path to the folder where you extracted it, and your antivirus product.

Click to expand...

Процесът C:\Windows\SysWOW64\shutdown.exe (DESKTOP-GURKHTK) започна изключване на компютър ...
Код на причина: 0x800000ff
Тип на изключване: изключване

• It is a planned, software-initiated shutdown, not a crash and not a power fault. If it were hardware you would see only Kernel-Power 41 with no 1074.
• The call came from SysWOW64\shutdown.exe — that is the 32-bit shutdown, so a 32-bit process invoked it. xDecoder is 32-bit. A hardware or driver problem cannot produce this.
• Your timestamps (0:26:55, 0:32:10, 0:44:51, 1:27:33) line up with your attempts — one 1074 per time you opened a vehicle file.

• Monitoring/debugging tools running or installed — x64dbg, OllyDbg, IDA, сhеаt Engine, Process Hacker/System Informer, Process Monitor, Process Explorer, HxD with a driver, API monitors, Wireshark. Close them and also check they are not running as a service or tray process.
• Virtual machine — VMware, VirtualBox, Hyper-V (note: having Hyper-V / Virtual Machine Platform / WSL enabled on a physical laptop can be enough for some checks). Tell me whether this is bare metal or a VM.
• Antivirus modified or quarantined a file after you extracted it. The check then fails and it shuts down. Add a full-folder exclusion for C:\xDecoder first, then delete the folder, re-extract from the archive, and launch via START-xDecoder.exe as administrator.
• Mixed files from an older xDecoder version in the same folder, or an incomplete/corrupted download. Re-download and compare the archive size against the resource (7,807,488 bytes for the package).

HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\shutdown.exe
 Debugger (REG_SZ) = cmd.exe /c exit

• Physical laptop or virtual machine? Is Hyper-V / WSL enabled?
• Which antivirus, and does its quarantine/protection history show anything for the xDecoder folder?
• Full path you extracted to, and confirmation you started with START-xDecoder.exe as administrator.
• Windows version/build.
• Result of the IFEO test above, if you run it — screenshot of whatever message appears.

Gemini said:

Thanks, this screenshot answers the question completely.

What this proves

Event ID 1074, Source User32, and this line:

Code:

Процесът C:\Windows\SysWOW64\shutdown.exe (DESKTOP-GURKHTK) започна изключване на компютър ...
Код на причината: 0x800000ff
Тип на изключване: изключване

Facts from the log:

• This is a planned, software-initiated shutdown, not a crash or power failure. If it were hardware-related, you would only see Kernel-Power 41 without 1074.
• The call came from SysWOW64 \shutdown.exe — this is the 32-bit shutdown utility, so a 32-bit process invoked it. xDecoder is 32-bit. A hardware or driver issue cannot cause this.
• Your timestamps (0:26:55, 0:32:10, 0:44:51, 1:27:33) match your attempts — one 1074 for each time you opened a vehicle file.

So this is exactly what is happening with TNLB7: the program's protection routine is invoked shutdownthe moment it loads a BIN file. The reason code 0x800000ff is simply “planned / other,” hardcoded — it provides no additional information.

What actually triggers it

The protection is triggered when it detects an analysis environment or a modified installation. In order of how frequently each turns out to be the cause:

• Monitoring/debugging tools running or installed — x64dbg, OllyDbg, IDA, сhеаt Engine, Process Hacker/System Informer, Process Monitor, Process Explorer, HxD with a driver, API monitors, Wireshark. Close them and check whether any are running as a service or system tray process.
• Virtual machine — VMware, VirtualBox, Hyper-V (note: enabling Hyper-V / Virtual Machine Platform / WSL on a physical laptop may be enough to trigger some checks). Tell me whether this is bare metal or a VM.
• The antivirus modified or quarantined a file after you extracted it. The subsequent check fails and the program shuts down. C:\xDecoder First, add a full exclusion for the folder, then delete the folder, extract it from the archive again, and run it as START-xDecoder.exeadministrator.
• Mixed files from an older version of xDecoder in the same folder, or an incomplete/corrupted download. Download it again and compare the archive size with the resource (7,807,488 bytes for the package).

Diagnostic test if you want to see what happens next

You can temporarily neutralize the shutdown call so that the program continues and displays its actual error instead of killing the machine. Create this key:

[КОД=текст]HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Опции за изпълнение на образен файл\shutdown.exe
Debugger (REG_SZ) = cmd.exe /c exit[/CODE]

This redirects only the 32-bit version shutdown.exe, so the protection call does nothing. Open the vehicle file again and note whether you get an error dialog, a silent exit, or whether it works. Delete this key afterward — leaving it there breaks normal shutdown from 32-bit applications. This is a test to identify the cause, not a solution.

What I need from you

• Physical laptop or virtual machine? Is Hyper-V / WSL enabled?
• Which antivirus software are you using, and does its quarantine/protection history show anything related to the xDecoder folder?
• The full path where you extracted it, and confirmation that you started it START-xDecoder.exeas administrator.
• Windows version/build.
• The result of the IFEO test above, if you run it — a screenshot of the message that appears.

Click to expand...

ENISCO said:

So, what should I do now? Should I try it on a virtual machine or something else?

Click to expand...

takeown /f C:\Windows\SysWOW64\shutdown.exe
icacls C:\Windows\SysWOW64\shutdown.exe /deny "%USERNAME%":(RX)

icacls C:\Windows\SysWOW64\shutdown.exe /remove:d "%USERNAME%"

• Windows edition and build (winver)
• Which antivirus is installed (and whether it is Defender only)
• The exact folder path you extracted to — non-ASCII characters in the path have caused trouble before
• Vehicle / ECU and the file you are trying to open (e.g. EDC17C64, MD1CS004), plus file size
• The screenshot from step 1

Gemini said:

Short answer: no, do not use a virtual machine. That is the environment most likely to make things worse. The protections used in tools of this type routinely check for hypervisors, and the usual response is exactly what you are seeing—a silent error shutdown /s /f /t 0. If it is run in a virtual machine, you will be troubleshooting two problems instead of one. Keep it on real hardware.

Since the log has already proven that a 32-bit process is initiating the shutdown, what remains is to determine what the tool is objecting to. Go through this in order.

1. First, make the shutdown harmless
This is the most useful step because the machine is currently shutting down before you can read an error message. From an elevated command prompt, deny your account permission to execute the 32-bit shutdown binary:

[КОД=cmd]изтегляне /f C:\Windows\SysWOW64\shutdown.exe
icacls C:\Windows\SysWOW64\shutdown.exe /deny "%USERNAME%"RX)[/CODE]

Now launch xDecoder and open the car file again. The shutdown call will fail, and whatever message or behavior the protection is designed to show will remain on the screen—this usually reveals the actual trigger immediately. Take a screenshot.

When you are finished, restore it:

[КОД=cmd]icacls C:\Windows\SysWOW64\shutdown.exe /remove:d "%ПОТРЕБИТЕЛСКОИМЕ%"[/КОД]

(The 64-bit copy System32is untouched, so normal Windows shutdown still works.)

2. Close anything the protection could interpret as analysis tools
Before the next test, close and preferably uninstall: Process Monitor, Process Hacker / Process Explorer, x64dbg, OllyDbg, IDA, сhеаt Engine, Wireshark, any sandbox, and virtual-drive software such as Daemon Tools or Alcohol. Also check that nothing similar is in the startup list. This group is the second most common trigger after virtual machines.

3. Antivirus—exclude, then extract again
Add the entire C:\xDecoderfolder as an exclusion in Defender/your antivirus software and then extract the archive again. If a file was quarantined during the first extraction, adding the exclusion afterward does not restore it, and the missing component causes the same symptom.

4. Check that the download is complete
The resource lists the package size as 7,807,488 bytes. Compare that with the downloaded file; if its size differs, download it again before doing anything else.

5. Narrow it down to the file or the program
Try opening a different, small BIN file from another ECU family. If every file shuts down the machine, it is an environment/protection issue. If only one file does it, it is a parsing issue with that specific strategy and requires a completely different solution.

To continue troubleshooting, I need:

• Windows edition and build ( winver)
• Which antivirus is installed (and whether it is only Defender)
• The exact path to the folder where you extracted it—non-ASCII characters in the path have caused problems before
• The vehicle / ECU and the file you are trying to open (e.g. EDC17C64, MD1CS004), plus the file size
• The screenshot from step 1

Click to expand...

ENISCO said:

I wrote the code and it works—it opens and runs. But I have one question: is this code harmful?

Click to expand...

• If you just renamed or replaced shutdown.exe (or dropped a dummy stub in its place), that is not malware and nothing is being damaged. The only side effect is system-wide: Windows' own command-line shutdown/restart no longer works normally until you restore the original. Keep the original shutdown.exe backed up so you can put it back.
• If you used a small wrapper/redirect that swallows the /s /f /t 0 call, same thing — harmless, but it affects every program that calls shutdown, not just xDecoder.

• Back up the original file so you can revert cleanly.
• Remember the override is active — if one day a legitimate restart "does nothing," this is why.

Gemini said:

Okay—if it now opens and stays open, that confirms the diagnosis: the tool itself was issuing the shutdown signal, and you have neutralized that call.

Whether it is “harmful” depends on exactly what you entered, so tell me which approach you chose:

• If you just renamed or replaced shutdown.exe (or placed a dummy file in its place), this is not malware and nothing has been damaged. The only side effect is system-wide: Windows' own command-line shutdown/restart no longer works normally until you restore the original. Keep a shutdown.exebackup copy of the original so you can restore it.
• If you used a small wrapper/redirect that swallows the /s /f /t 0call, the same applies—it is harmless, but it affects every program that invokes shutdown, not just xDecoder.

So, the method itself is not dangerous, but it is a blunt instrument. It does not remove the tool's self-protection; it merely stops the symptom. That is fine for getting the job done, but keep two things in mind:

• Back up the original file so you can revert cleanly.
• Remember that the override is active—if a legitimate restart “does nothing” one day, this is why.

Paste the exact code/command you used, and I will tell you exactly what it does and whether anything needs to be fixed.

Click to expand...

ENISCO said:

I just entered the first code in the command prompt. Will it harm anything else?

Click to expand...

• What changes: Windows' own command-line shutdown/restart (the shutdown command, and anything that calls shutdown.exe to power off or reboot) stops working normally. That's the whole point — it's what blocks the tool from killing your session.
• What does NOT change: No files are deleted, no system corruption, no malware, no effect on your drivers, your ECU files, or any other program. Shutting down from the Start menu still works through a different path, so you're not locked out.

BoxBox said:

17946D4E164746E1

Click to expand...

tobi55441 said:

---------------------------
xDecoder 14.0
---------------------------
License is not installed or is invalid.



HWID: 5C02628EDC981DA0



HWID copied to clipboard.



Import the key .reg file and start xDecoder again.



binunlock.com
---------------------------
OK
---------------------------

Please activate the program.

Click to expand...

mkke said:

HELLO,

HWID: 0A47A94E99CE2D4C

THANK YOU VERY MUCH!

Click to expand...