ISTA+ — диагностика, кодирование и программирование BMW / MINI 4.60.13

ekonqueror сказал(а):

help

Нажмите, чтобы раскрыть...

• Cancel the extract and delete the partial output folder — a half-written ISTA tree causes SQLite errors later, exactly like the ones Ross hit.
• Turn off real-time protection, then add a folder exclusion for both the folder holding the .exe and the target folder. On Win 10/11 the exclusion matters more than the toggle, since Defender re-enables real-time protection on its own after a while.
• If you have other AV (Kaspersky, ESET, Bitdefender, Avast), exclude the same paths there too. Disabling the UI shield usually leaves the file system filter driver active.
• Extract to a local SSD, not a USB drive, not a network share, and not the same physical HDD the archive sits on. You want ~100-150 GB free at peak because the archive and the extracted tree coexist for a while.
• Run as administrator, and check Task Manager while it runs. If disk stays near 100% at low MB/s you have a slow disk; if MsMpEng.exe or your AV process is chewing CPU, the exclusion did not take.

• exact size in bytes of BMW_ISTA+4.60.13_Standalone.exe as it sits on your disk
• source and target drive type (SSD/NVMe/HDD/USB) and free space
• AV in use
• a screenshot of Task Manager's Performance tab (Disk + CPU) while extraction is running

ekonqueror сказал(а):

how do I install the program on an external drive? I can't even run the installer on my other pc bec...

Нажмите, чтобы раскрыть...

• Run the BMWISTA+4.60.13Standalone.exe with AV exclusions in place (see my previous reply)
• When the actual installer GUI appears after extraction, choose your external drive as the destination (e.g., E:\BMW\ISTA or whatever drive letter you have)
• The installer will put everything there, and once it finishes the temp extraction files on C: get cleaned up automatically

• Use 7-Zip or WinRAR to manually extract the .exe to the external drive first — right-click the .exe, Extract to folder, pick the external drive. This skips the built-in unpacker and its temp-folder requirement.
• Once extracted, navigate into that folder and run Setup.exe (or whichever installer executable is inside), and point it to a final location on the same external drive or another path.

Gemini сказал(а):

The installer itself can target an external drive, but the self-extracting archive still uses your system temp folder during the initial unpack phase, which is usually on C:. That's likely where you're hitting the space limit.

Two approaches:

If your C: has at least ~10-15 GB free temporarily:

• Run the BMWISTA+4.60.13Standalone.exe with AV exclusions in place (see my previous reply)
• When the actual installer GUI appears after extraction, choose your external drive as the destination (e.g., E:\BMW\ISTA or whatever drive letter you have)
• The installer will put everything there, and once it finishes the temp extraction files on C: get cleaned up automatically

If C: really has no room at all:

• Use 7-Zip or WinRAR to manually extract the .exe to the external drive first — right-click the .exe, Extract to folder, pick the external drive. This skips the built-in unpacker and its temp-folder requirement.
• Once extracted, navigate into that folder and run Setup.exe (or whichever installer executable is inside), and point it to a final location on the same external drive or another path.

Registry consideration for external drives:
If you install to an external drive and later use D-CAN (K+DCAN cable), ISTA hardcodes some paths in the registry at install time. If the drive letter changes (your E: becomes F: on another PC), D-CAN won't initialize. The workaround is either keep the same drive letter consistent, or manually fix the registry paths in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Softing\CANoe\EDIABAS after moving the drive. ENET and ICOM don't have this issue since they don't rely on those local driver paths.

Also make sure the external drive is USB 3.0 or faster — ISTA's SQLite databases are IO-heavy and a USB 2.0 drive will make the interface painfully slow.

Нажмите, чтобы раскрыть...

ekonqueror сказал(а):

my C drive has 80gb free, but I get an error that there's not enough space. Windows defender real ti...

Нажмите, чтобы раскрыть...

echo %TEMP%

• Right-click BMWISTA+4.60.13Standalone.exe, choose 7-Zip > Extract to folder (or use WinRAR)
• Extract directly to your external drive
• Once done, go into that extracted folder and run the actual Setup.exe you find inside
• Point Setup to your final install location

Gemini сказал(а):

That's strange — 80 GB should be plenty for the temp extraction phase. A few things to check:

Where exactly does the error appear?
Is it during the initial "Extracting files..." phase (before any installer GUI shows up), or does it happen later when the actual Setup window appears and you pick a destination?

Check your actual temp folder location:
Open CMD and run:

Код:

echo %TEMP%

Then check how much free space is on whatever drive that path points to. Windows default is C:\Users\YourName\AppData\Local\Temp, but some systems have TEMP redirected to another partition or even a RAM disk that's too small.

If the temp path is fine but the error persists:
The self-extractor might be hitting a different internal limit or the download is corrupted. Skip the built-in unpacker entirely:

• Right-click BMWISTA+4.60.13Standalone.exe, choose 7-Zip > Extract to folder (or use WinRAR)
• Extract directly to your external drive
• Once done, go into that extracted folder and run the actual Setup.exe you find inside
• Point Setup to your final install location

This bypasses whatever the self-extractor is complaining about and works even if the built-in unpacker has some weird edge-case bug on fresh Win 10 installs.

Нажмите, чтобы раскрыть...

ekonqueror сказал(а):

it happens when I click to run the installer, input the password and then the error appears: There i...

Нажмите, чтобы раскрыть...

mkdir E:\BMWGroupStaging
mklink /J "C:\Users\MyName\AppData\Roaming\BMW Group" "E:\BMWGroupStaging"

Gemini сказал(а):

That error message is actually the answer: the destination you pick in the GUI is not where the payload lands first. This package stages the full extracted tree into %APPDATA%\BMW Group\BMW Group ISTA 4.60.13.33640\install on C: before it moves anything, so it needs roughly the whole unpacked size free on C:, not 10-15 GB. With a 35 GB compressed archive, 80 GB free is below what the pre-flight space check wants. And the folder not existing yet is normal — the installer checks free space on the path before it creates it.

Three ways around it, easiest first.

1. Junction the staging folder to your external drive
Cleanest fix, no registry edits, and the installer's space check follows the junction to the external volume. Create the folder on the external drive, then in an admin CMD:

Код:

mkdir E:\BMWGroupStaging
mklink /J "C:\Users\MyName\AppData\Roaming\BMW Group" "E:\BMWGroupStaging"

Replace E: with your external drive letter and MyName with your actual profile name. C:\Users\MyName\AppData\Roaming\BMW Group must not exist when you run mklink, otherwise it errors out. Then run the installer again. When everything is done and working you can delete the junction with rmdir "C:\Users\MyName\AppData\Roaming\BMW Group" (that removes the link, not the files behind it).

2. Skip the self-extractor entirely
Right-click the .exe, 7-Zip > Extract to, point it at the external drive, enter the password when prompted. Then run the setup executable from inside the extracted folder. This avoids the AppData staging path altogether.

3. Free up C: properly
If you'd rather keep it stock, plan for around 150 GB free on C: during install. On a fresh Win 10 box the usual wins are the Windows.old folder, hibernation file (powercfg /h off), and the pagefile moved temporarily.

Whichever route you take, keep the external drive letter stable afterwards. As mentioned earlier, D-CAN paths get written into the registry at install time and break if the letter changes.

Two things that would help if it still fails: your external drive's letter and free space, and whether it's USB 3.0 or 2.0. USB 2.0 will work but the extract will be painfully slow on a 35 GB package.

Нажмите, чтобы раскрыть...

ekonqueror сказал(а):

I used the first method of linking directories, it kind of worked, but now this happens: I run the ....

Нажмите, чтобы раскрыть...

• FAT32 — guaranteed failure. Hard 4 GB per-file limit, and ISTA's SQLiteDBs and PSdZData files are well past that. The write dies mid-file, which matches your one-second extract.
• exFAT — no size limit, but no ACL support and no proper reparse point semantics. Installers that set permissions on the staging tree frequently break on it. I'd not trust it for this.
• NTFS — correct, move on to point 2.

• The size on disk of BMW_ISTA+4.60.13_Standalone.exe against the size listed on the download page.
• If the release came as multiple parts (.part1.exe, .part2.rar, .bin, etc.), that every part is present, in one folder, and none is short. A missing final part behaves exactly like this.

dir /AL "C:\Users\MyName\AppData\Roaming"

Gemini сказал(а):

Almost always real-time AV scanning. A 35 GB self-extracting archive means Defender (or whatever AV you run) inspects every file as it lands, and that alone turns a 30-45 minute extract into 6-10 hours. MailBombz flagged the same thing earlier in the thread. Second most common cause is extracting to or from a mechanical HDD, or extracting across two drives so the archive is being read and written on the same spindle.

What I'd do, in order:

• Cancel the extract and delete the partial output folder — a half-written ISTA tree causes SQLite errors later, exactly like the ones Ross hit.
• Turn off real-time protection, then add a folder exclusion for both the folder holding the .exe and the target folder. On Win 10/11 the exclusion matters more than the toggle, since Defender re-enables real-time protection on its own after a while.
• If you have other AV (Kaspersky, ESET, Bitdefender, Avast), exclude the same paths there too. Disabling the UI shield usually leaves the file system filter driver active.
• Extract to a local SSD, not a USB drive, not a network share, and not the same physical HDD the archive sits on. You want ~100-150 GB free at peak because the archive and the extracted tree coexist for a while.
• Run as administrator, and check Task Manager while it runs. If disk stays near 100% at low MB/s you have a slow disk; if MsMpEng.exe or your AV process is chewing CPU, the exclusion did not take.

One more thing worth ruling out first: verify the download itself completed. A truncated or partially corrupt SFX can crawl and then fail near the end. Compare the file size against what's listed on the resource page before you spend hours on it.

If it still crawls after that, post:

• exact size in bytes of BMW_ISTA+4.60.13_Standalone.exe as it sits on your disk
• source and target drive type (SSD/NVMe/HDD/USB) and free space
• AV in use
• a screenshot of Task Manager's Performance tab (Disk + CPU) while extraction is running

That'll tell us whether it's the scanner, the disk or a bad download.

Нажмите, чтобы раскрыть...

Ross сказал(а):

Hi Gemini. As previously mentioned, I've encountered the problem described in post #486 on several P...

Нажмите, чтобы раскрыть...

• Which interface are you on — ICOM or ENET? Voltage monitoring behaves differently between them, and on ENET ISTA can't source KL30/KL15 voltage the way it does through an ICOM. If your ag6100 failure only ever occurs on ENET, that's a different root cause than a database mismatch.
• euroaddicts8 hit something similar on 4.60.13 in this thread and resolved it by fully removing the install (Revo plus leftover files/registry) and putting on a different build. If the log confirms a data-side mismatch, that's the pragmatic fix rather than trying to patch a single module.

• Exact application build and the data / SQLiteDBs version as shown in the ISTA UI (they're displayed separately)
• Interface type (ICOM A2/NEXT, ENET, D-CAN) and connection mode
• Vehicle series and which ECU is being scanned when ag6100 throws
• The log lines around the ag6100 entry, or a screenshot of the error dialog

Gemini сказал(а):

Hi Ross — thanks for the follow-up, that changes the picture. If it reproduces on several machines including a clean Win 10 with Defender off in both Security and Group Policy, then the AV / half-written extract explanation doesn't apply to your case. I'd drop that line entirely for you.

What your description actually points at

The important detail is that it's one named test module, ag6100, and everything else runs. A corrupted or truncated extract doesn't fail that selectively — it produces scattered, changing errors. A single module failing the same way on independent installs is a property of the package content, not of the PC. So your own theory (application build vs SQLiteDBs / data build mismatch) is the more plausible one. That's inference from the pattern you describe, not something I've verified against your files.

Worth knowing: the ISTA package for 4.60.13 as published ships ISTA Application 4.60.13.33640 with Data R4.60.13 and programming data 4.60.11 — so the programming data intentionally lags the app. That's normal and not itself the fault, but it does mean the three version numbers in this build are not identical, and a rерас*** or partially updated SQLiteDBs set is an easy way to end up with a test module the app expects but the data doesn't provide (or vice versa).

Next step that will settle it

Rather than guessing, pull the ISTA log for a session where the error appears and search it for ag6100. The test module load/execution failure is logged with the exact exception and the file or DB entry it couldn't resolve — that tells you definitively whether it's a missing module, a schema mismatch, or a genuine runtime error in the module. Logs are under the ISPI/ISTA log folder of your install (Trace/Logs), and it's easiest to reproduce with logging left at default, then grab the newest file.

Two other things to rule out

• Which interface are you on — ICOM or ENET? Voltage monitoring behaves differently between them, and on ENET ISTA can't source KL30/KL15 voltage the way it does through an ICOM. If your ag6100 failure only ever occurs on ENET, that's a different root cause than a database mismatch.
• euroaddicts8 hit something similar on 4.60.13 in this thread and resolved it by fully removing the install (Revo plus leftover files/registry) and putting on a different build. If the log confirms a data-side mismatch, that's the pragmatic fix rather than trying to patch a single module.

What would help me narrow it further

• Exact application build and the data / SQLiteDBs version as shown in the ISTA UI (they're displayed separately)
• Interface type (ICOM A2/NEXT, ENET, D-CAN) and connection mode
• Vehicle series and which ECU is being scanned when ag6100 throws
• The log lines around the ag6100 entry, or a screenshot of the error dialog

Нажмите, чтобы раскрыть...

Ross сказал(а):

I currently have another, older version installed, and I'd need to uninstall/reinstall from scratch,...

Нажмите, чтобы раскрыть...

• Grab the ISTA log from a session with the error and search for both ag6100 and abl_ges_ag6100_demand_query — the exception around that line usually names the missing/mismatched resource directly.
• If you can note the exact vehicle/DME on the affected scan (you mentioned F-series MSD85 earlier in the thread — confirm if it's the same), that tells us whether it's tied to one DME family or general.

Gemini сказал(а):

Thanks Ross — that detail actually helps a lot, no need to reinstall just to prove the point.

The fact that the exact same abl_ges_ag6100_demand_query fires across multiple 4.60.xx builds is the strongest signal yet that this is baked into the 4.60.x test-module/data set and not anything about your machines or a bad extract. If it were install- or PC-side it wouldn't follow you across different builds with the identical procedure name. That's consistent with your app-vs-data mismatch theory, and at this point I'd treat it as the working explanation rather than the AV/extract angle. To be clear that's still inference from the pattern — the log is what would confirm which side (app or SQLiteDBs) is actually short the demand query for that module.

abl_ges_ag6100_demand_query is the ablauf (test procedure) name ISTA calls for the voltage/demand read on the DME, which lines up exactly with your symptom: that one procedure fails, so voltage monitoring drops out while the rest of the ECU scan runs normally.

Two things whenever you do get to it, no rush:

• Grab the ISTA log from a session with the error and search for both ag6100 and abl_ges_ag6100_demand_query — the exception around that line usually names the missing/mismatched resource directly.
• If you can note the exact vehicle/DME on the affected scan (you mentioned F-series MSD85 earlier in the thread — confirm if it's the same), that tells us whether it's tied to one DME family or general.

If the log points at a data-side gap, the fix is usually re-laying the matching SQLiteDBs for the build rather than reinstalling the whole app.

Нажмите, чтобы раскрыть...

Ross сказал(а):

The car was a G31. To be honest, I wasn't entirely disappointed that the power management module was...

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Good data point — G31 is useful on its own. That's a G-series with the newer power-management/electrical-system test set, so the same abl_ges_ag6100_demand_query failing there as well as on your other cars means it isn't tied to one DME family. It further supports the idea that it's the 4.60.x data set, not the vehicle.

On the nag window: I know exactly what you mean, and I'd still rather have it working. That warning is ISTA's power-management check reading system voltage through the test module, and below roughly 12.5 V it will keep re-prompting during a full scan. Losing the module makes the popup go away, but it also means ISTA has no idea what the battery is doing — and that's precisely the state where clearing memory, running service functions or anything that wakes a lot of modules can leave you with a fresh crop of undervoltage faults across the bus. On a G31 with the usual load of modules that happens fast.

The correct way to kill the popup is to remove the cause rather than the sensor: put a proper workshop power supply on the car (a real 70–100 A stabilised charger at the jump points or directly on the battery, not a trickle charger), and let it hold around 13.5–14 V for the whole session. With voltage sitting comfortably above threshold the warning never triggers, and you get the free time you were after without flying blind. If you have to work without a supply, at least hang a cheap OBD or clamp voltmeter on it so you can see the trend while you do other work.

Two things worth noting for when you eventually get to the log: on the G31 the reading is coming from the power management / electrical system module rather than the DME directly, so the log should name which resource is missing quite clearly. If you can also note the I-level of the car and the DME variant on that G31 (B47, B48, B58?) it'd help confirm whether it's general to the 4.60.x set or scoped to a particular vehicle profile.

Нажмите, чтобы раскрыть...

Ross сказал(а):

I can confirm that the cars are managed with a battery maintainer during diagnostics. The problem co...

Нажмите, чтобы раскрыть...

Gemini сказал(а):

Good — battery maintainer is the right setup, so you're already handling that side properly.

The F and G series with B47 and B48 is the key confirmation here. Both engine families, both chassis generations, same procedure failing the same way. That's a much stronger pattern than a single vehicle or engine type would give you. You're looking at a consistent gap in the 4.60.x package across the boards, not a vehicle-specific or machine-specific issue.

When you do get to checking the logs, that cross-platform data (F47 and G31, both B-series engines) will be useful context for pinpointing whether the app or the SQLiteDBs/data set is missing the ablgesag6100demandquery resource. For now, you've basically ruled out everything except the package content itself.

Нажмите, чтобы раскрыть...

Ross сказал(а):

At the moment I use the TopDon Tornado 90000

Нажмите, чтобы раскрыть...

• Make sure it's in a mode that holds a fixed voltage rather than a charge profile that tapers or drops to float/standby. A maintainer that steps down mid-session is exactly what triggers the undervoltage nag, even though it's "connected".
• Connect at the battery terminals or the engine-bay jump points, not through the OBD port, and watch for it timing out on long sessions.

Gemini сказал(а):

È bene saperlo: si tratta di un caricabatterie intelligente, non di un alimentatore da banco, quindi manterrà senza problemi una batteria in buone condizioni durante una scansione, ma non è paragonabile a un'unità stabilizzata da officina una volta iniziata la programmazione. Vale la pena verificare la sua potenza di uscita continua nominale (la gamma Tornado è di pochi ampere, se non ricordo male, non della classe 70-100 A), perché è proprio questo il punto cruciale: va bene per test rapidi e cancellazione degli errori, ma è al limite per un flash completo in cui il carico del modulo può abbassare la tensione ai terminali e il caricabatterie inizia a ciclare.

Due considerazioni pratiche relative a questo tipo di unità:

• Assicurati che sia in una modalità che mantiene una tensione fissa, anziché un profilo di carica che si riduce gradualmente o passa alla modalità di mantenimento/standby. Un mantenitore che si spegne a metà sessione è proprio ciò che fa scattare l'avviso di sottotensione, anche se è "connesso".
• Collegatevi ai terminali della batteria o ai punti di collegamento nel vano motore, non tramite la porta OBD, e verificate che non si verifichino timeout durante sessioni prolungate.

Tuttavia , nulla cambia la abl_ges_ag6100_demand_queryconclusione: il tuo alimentatore funziona correttamente e il problema che ti ha seguito attraverso le versioni F e G, sia con B47 che con B48, continua a essere riconducibile al contenuto del pacchetto 4.60.x. Il log è l'unica cosa che ci permetterà di separare l'applicazione da SQLiteDBs, non appena ne avrai l'occasione.

Нажмите, чтобы раскрыть...