IgniteRemote v1.7.1

Ctrl+Alt+Del now works, and every remote action reports what actually happened.

Ctrl+Alt+Del is a Secure Attention Sequence, so injected keystrokes can never produce it. The agent already called SendSAS, but the SoftwareSASGeneration policy that makes SendSAS do anything was never set — and SendSAS returns void, doing nothing when refused. The log read "Ctrl+Alt+Del sent." while the machine sat there.

Installing Admin Mode now sets that policy, and the handler checks both prerequisites before calling so it names whichever is missing instead of claiming success.

The same pattern ran through the other actions. Lock discarded the boolean LockWorkStation returns, so a refusal logged as a success. Restart, shutdown and sign-out logged the command line on launch, but starting shutdown.exe says nothing about acceptance — it exits 5 on access denied and 1115 when a shutdown is already pending. All of them now check and report the real reason.

Note: the Ctrl+Alt+Del fix takes effect when Admin Mode is installed, since that is the elevated moment where the policy is written. On a machine that already has Admin Mode, turn it off and on again.

IgniteRemote v1.7.0

New: customer mode

Some computers running IgniteRemote belong to customers, not staff — a shop that booked a
single remote job and installed the agent with a setup code. Those machines now know what
they are: Unattended Access, Admin Mode and USB Settings disappear from the tray menu
and the main window, so the promise made at booking — nobody connects without you clicking
approve — cannot be switched off by anyone, including us.

Hidden rather than greyed out, on purpose: a disabled switch invites the question of how to
enable it, and on these machines the honest answer is that it does not apply. Tool sharing
stays — it is the entire reason the agent is on that machine.

The mode is remembered permanently and never reverses on its own. A machine that briefly
cannot reach the server does not quietly get the controls back.

New: End session — a button, not a promise

The live-session banner told you who was connected and how long they had been there, and
gave you nothing to do about it. There is now an End session button in the banner.

It stops the screen locally FIRST — before telling the server — so no slow network or
expired login can keep a session alive after you have said stop. If the server cannot be
reached afterwards, the log says plainly that nothing is being shared either way.

No confirmation dialog. Someone clicking this wants it to stop now; restarting a session
costs a phone call, and the other mistake does not undo.

IgniteRemote v1.6.32

New: customer mode

Some computers running IgniteRemote belong to customers, not staff — a shop that booked a
single remote job and installed the agent with a setup code. Those machines now know what
they are: Unattended Access, Admin Mode and USB Settings disappear from the tray menu
and the main window, so the promise made at booking — nobody connects without you clicking
approve — cannot be switched off by anyone, including us.

Hidden rather than greyed out, on purpose: a disabled switch invites the question of how to
enable it, and on these machines the honest answer is that it does not apply. Tool sharing
stays — it is the entire reason the agent is on that machine.

The mode is remembered permanently and never reverses on its own. A machine that briefly
cannot reach the server does not quietly get the controls back.

New: End session — a button, not a promise

The live-session banner told you who was connected and how long they had been there, and
gave you nothing to do about it. There is now an End session button in the banner.

It stops the screen locally FIRST — before telling the server — so no slow network or
expired login can keep a session alive after you have said stop. If the server cannot be
reached afterwards, the log says plainly that nothing is being shared either way.

No confirmation dialog. Someone clicking this wants it to stop now; restarting a session
costs a phone call, and the other mistake does not undo.

IgniteRemote v1.6.31

Fixed: sessions that were never answered

Connecting to a computer would sit at "waiting for the computer to accept" forever, while that
computer looked perfectly healthy. The cause took an evening to corner because every part
involved was silent: the background service that accepts sessions had a worker inside it die
quietly — the service still showed "Running", its log showed nothing, and the server was
offering each session to a task that no longer existed.

Two changes:

The service now watches itself. If its session-accepting worker goes quiet for two
minutes, it is restarted automatically and the log says so. And a healthy service now writes a
brief liveness line every ten minutes — so from now on, a silent log can only mean a dead
service, never an ambiguous one.

The server writes down every offer. The moment a session is offered to a computer, a line
appears in that computer's log (visible in the console's Logs page). A session that hangs now
tells you which side dropped it, in one look.

Also fixed on the server today: a brief push-connection blip no longer makes the console call
a healthy machine "offline".

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.30

Fixed: sessions that were never answered

Connecting to a computer would sit at "waiting for the computer to accept" forever, while that
computer looked perfectly healthy. The cause took an evening to corner because every part
involved was silent: the background service that accepts sessions had a worker inside it die
quietly — the service still showed "Running", its log showed nothing, and the server was
offering each session to a task that no longer existed.

Two changes:

The service now watches itself. If its session-accepting worker goes quiet for two
minutes, it is restarted automatically and the log says so. And a healthy service now writes a
brief liveness line every ten minutes — so from now on, a silent log can only mean a dead
service, never an ambiguous one.

The server writes down every offer. The moment a session is offered to a computer, a line
appears in that computer's log (visible in the console's Logs page). A session that hangs now
tells you which side dropped it, in one look.

Also fixed on the server today: a brief push-connection blip no longer makes the console call
a healthy machine "offline".

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.29

Fixed: sessions that were never answered

Connecting to a computer would sit at "waiting for the computer to accept" forever, while that
computer looked perfectly healthy. The cause took an evening to corner because every part
involved was silent: the background service that accepts sessions had a worker inside it die
quietly — the service still showed "Running", its log showed nothing, and the server was
offering each session to a task that no longer existed.

Two changes:

The service now watches itself. If its session-accepting worker goes quiet for two
minutes, it is restarted automatically and the log says so. And a healthy service now writes a
brief liveness line every ten minutes — so from now on, a silent log can only mean a dead
service, never an ambiguous one.

The server writes down every offer. The moment a session is offered to a computer, a line
appears in that computer's log (visible in the console's Logs page). A session that hangs now
tells you which side dropped it, in one look.

Also fixed on the server today: a brief push-connection blip no longer makes the console call
a healthy machine "offline".

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.28

Fixed: sessions that were never answered

Connecting to a computer would sit at "waiting for the computer to accept" forever, while that
computer looked perfectly healthy. The cause took an evening to corner because every part
involved was silent: the background service that accepts sessions had a worker inside it die
quietly — the service still showed "Running", its log showed nothing, and the server was
offering each session to a task that no longer existed.

Two changes:

The service now watches itself. If its session-accepting worker goes quiet for two
minutes, it is restarted automatically and the log says so. And a healthy service now writes a
brief liveness line every ten minutes — so from now on, a silent log can only mean a dead
service, never an ambiguous one.

The server writes down every offer. The moment a session is offered to a computer, a line
appears in that computer's log (visible in the console's Logs page). A session that hangs now
tells you which side dropped it, in one look.

Also fixed on the server today: a brief push-connection blip no longer makes the console call
a healthy machine "offline".

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.27

Fixed: the tool connection died over nothing

Twice in one afternoon, a healthy connection between two computers on the same network dropped
mid-session. The logs told us why: the link declared its partner dead after twelve rapid retries
of a single packet — which, on a fast network, takes about two seconds. Any two-second
hiccup (Wi-Fi scanning channels, an access point handing off) was a death sentence for a link
that was otherwise fine.

Three changes:

A link now dies of silence, not impatience. It gives up only when nothing at all has been
heard from the other computer for fifteen seconds. Short stalls are ridden out; retries continue
as long as the other end is audibly alive. A flash needs the link to hold for twenty minutes,
and this is what makes that realistic on real-world Wi-Fi.

A quiet link stays warm. A small keepalive flows every five seconds when there is no
traffic, so Wi-Fi power saving does not doze off on us and problems are noticed while they are
still small.

If it drops anyway, it redials itself. The computer driving the tool now reconnects
automatically — up to three attempts — and says so. If your diagnostic software showed an error
during the gap, just retry the operation; the tool comes back on its own. Deliberately
disconnecting is respected and never redialled.

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.26

Fixed: the last update blocker

The installer's own log — now sent to us automatically — captured the failure word for word:
GM's Techline Connect keeps a proxy component running that holds our J2534 file open. Windows'
"close the apps using these files" mechanism could not close it, and a silent update answered
its own question with Abort and rolled everything back.

That mechanism is now off. The installer handles busy files itself: parts of IgniteRemote are
closed properly, and a file held open by someone else's software is renamed aside rather than
deleted — Windows permits exactly that — so the new file always lands. Software that was open
during an update keeps running on the old copy until it restarts, which is the same approach
Windows Update uses.

Updates no longer require closing anything, GM software included.

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.

IgniteRemote v1.6.25

Fixed: updating while your diagnostic software is open

The update failure finally produced its error message, and it named the real culprit: not a
stray helper process, but the diagnostic software itself. GM's software loads our J2534 file
into itself — that is the entire point of it — and Windows refuses to delete a file that a
running program has loaded. So an update attempted while GDS2, Techline Connect or TDS was
open died on that exact file. Run silently, it died invisibly.

Windows does allow such a file to be renamed. The installer now moves the old file aside
instead of deleting it: your diagnostic software keeps running on the copy it already loaded,
the new file lands in place, and the leftover is swept up by the next update. You no longer
need to close anything to update.

One honest note: diagnostic software that was open during the update keeps using the OLD
version of the file until that software is restarted. Restart it when convenient.

Nothing starts recording on update

Unchanged: recording is off on every computer and stays off until an owner completes the
attestation in the console and switches it on for that specific computer.