SSD Toolbox schedule..?

The SSD Toolbox is exceedingly finicky about its schedule. More than half the time, it does not actually remember it when it is set. And then it loses it after a single run.

It would be great if Corsair would fix it. (It would be better if it integrated with the Windows Task Scheduler.)

However, in the mean time, I would like to know: What is the mechanism for keeping the schedule? By this, I mean: Where is it stored? Is there a file? A registry setting?

If I knew what it was, I could set up a Task to re-create it periodically and restart the SSD Toolbox service. Maybe that would help me get around its flaws.

Anyone know?

Thanks

Hello ltwally

The issue looks similar to the below described bug N4.

There could be quite a lot of workarounds.

1.) Example 1.

The simplest way which comes in mind is to reset the LastExec to 0 every time (let’s say daily) when you need to run TRIM.

It could be something like this:

- send "pause” command to the service (net pause CorsairSSDToolBox):

- reset "LastExec" to 0 (reg.exe add "KeyGoesHere" /v "LastExec" /t reg_dword /d 0 /f);

- send "continue” command to the service (net continue CorsairSSDToolBox)

2.) Example 2.

This example uses slightly different approach. It does not rely on scheduler of Toolbox. It writes its own schedule to registry and asks the service to do its job.

The routine could look like this:

- stop/pause the service;

- set "ScheduleData" to current time (number of seconds passed from midnight. It could be the current time minus some seconds) and reset LastExec to 0;

- start/continue the service. It will start to TRIM immediately.

You can use this command line tool (you can also find different tool or write our own script) to get the number of seconds passed from midnight:

times (link1; link2).

Remarks:

1.) Please note that the value of DeviceID must be valid (it contains the version of firmware. So you should update your workaround each time when firmware is updated).

2.) More detailed description goes below.

to Corsair team and to everyone who experienced the issues with scheduled Trim in Corsair Toolbox

The scheduler of Corsair SSD Toolbox is completely broken.

It has multiple bugs. Each one of these bugs alone is quite enough to make a "scheduler” useless.

These bugs were reported many times. But who cares…

Bug reports:

- Scheduled Trim in SSD Toolbox deselected

- SSD Toolbox scheduled Trim keeps blanking??

- SSD Toolbox bug (?) - not possible to schedule Trim

Sorry for so long descriptions. I posted the simpler/shorter description 2 times.

There was no single reply and there was no other sign that these reports are noticed.

This is my last try to somehow bring the attention of the guys from Corsair to the topic.

1.) This bug is valid for Windows XP SP3 32bit. It’s valid for both v1.0 and v1.1 of Toolbox.

What is the mutex: to keep it simple we can consider that mutex = flag in memory.

It’s quite usual to use the mutexes to ensure that only one instance of your application is running.

How does it work? When GUI application (CSSDT.exe) starts it creates the "flag". Second instance doesn’t know anything about the first one.

It also tries to create this flag. The call from second instance fails with ERROR_ALREADY_EXISTS if the flag exists.

The 2nd instance gets known that it’s not "alone" and exits silently.

Technical description could be found by link: MSDN: CreateMutex function

So far so good…

But… The developers used the same flag (the same name of the mutex) for the service application (the service is "responsible" to run the scheduled trim in the background).

What were the consequences:

- it’s not possible to start the service if GUI is running. So it is even not possible to define a schedule;

The opposite is also correct. It’s not possible to start GUI (if you want to change the schedule, for example) if the service is running;

- it is not possible to start the service during the installation phase.

This approach (the same name of the mutex is used for both gui and service) works] on Vista+ because of "Session isolation". It does not work (and it never will) on XP.

Dear developers,

-- you should have noticed that the service (CSSDTService.exe) was never started when somebody installed the Toolbox on Windows XP.

This line from your InnoSetup installation script will never work properly on Windows XP/2003:

[Run]
Filename: "{app}\CSSDTService.exe"; Parameters: "/install /start"; Description: "Service Installation"; MinVersion: 0.0,5.0;)

The reason is the same.

This routine will never work properly on Windows XP:

CSSDTService.exe (user account) -> call to SCM (services.exe is running under NT AUTHORITY\SYSTEM) -> CSSDTService.exe (NT AUTHORITY\SYSTEM).

"CSSDTService.exe /install /start" starts under user account. It creates the mutex "SDSIM_CSSDT".

But it will never has a chance to start as a service in case if it’s already running as user application.

This is because of (yes, I hope you have noticed some light in the end of tunnel) your approach to use the mutexes. Yes, both instances of CSSDTService.exe share the same mutex with the same name.

-- you should not claim that Toolbox is compatible with Windows XP SP3 if you never even did the tests.

Here are the screnshots:

http://thumbnails109.imagebam.com/30244/995cf3302434246.jpg http://thumbnails110.imagebam.com/30262/6fd7d6302614929.jpg http://thumbnails110.imagebam.com/30244/148f33302434250.jpg http://thumbnails112.imagebam.com/30244/e05f51302434251.jpg http://thumbnails109.imagebam.com/30244/cfb461302434253.jpg

2.) This bug is valid for Windows XP SP3 32bit (could be valid for Vista+ also, but I have not tested it on Vista/7/8). Introduced in Toolbox v1.1 (it does not exist in v1.0)

The GUI writes the schedule to HKEY_CURRENT_USER ("HKCU\Software\Corsair\Corsair SSD Toolbox\1.1\SSDToolSchedule" to be precise). The service polls HKEY_CURRENT_USER also.

The value is the same. It is taken from configuration file (Cssdt.oem -> ScheduleRegistryPath).

So what is the problem ?

HKEY_CURRENT_USER is different for user account (the case of GUI) and for SYSTEM account (the case of service).

Is it clear? I think it should be clear for everyone who programs the service application.

But apparently it’s not…

CSSDT.exe writes the information about the task scheduled to "HKCU\Software\Corsair\Corsair SSD Toolbox\1.1\SSDToolSchedule"

CSSDTService.exe tries to find the settings in "HKU\.DEFAULT\Software\Corsair\Corsair SSD Toolbox\1.1\SSDToolSchedule"

Please find the screenshots attached:

http://thumbnails112.imagebam.com/30244/102f47302434254.jpg http://thumbnails109.imagebam.com/30244/9ebe1f302434255.jpg http://thumbnails109.imagebam.com/30244/e28114302434259.jpg

3.) This bug is valid for Windows XP SP3 32bit (should be valid for Vista+ also, I have not tested this behavior on Vista/7/8). Introduced in Toolbox v1.1 (does not exist in v1.0)

The GUI (CSSDT.exe) from Toolbox v1.1 deletes everything from HKCU\Software\Corsair\Corsair SSD Toolbox\1.1

(including all the sub-keys and values. The only exception is "DeviceSMARTCache" key) when a user closes it.

It means that the details of task scheduled via GUI are simply deleted every time you close GUI.

(To be honest , the logic here is more complex. It’s not a simple deletion but rather a rollback).

Please find the screenshots attached

http://thumbnails112.imagebam.com/30244/102f47302434254.jpg http://thumbnails109.imagebam.com/30244/9ebe1f302434255.jpg http://thumbnails110.imagebam.com/30244/4bce01302434256.jpg http://thumbnails109.imagebam.com/30244/8c3e9b302434257.jpg

4.) This bug is valid for Windows XP SP3 32bit (should be valid for Vista+ also, I have not tested this behavior on Vista/7/8). It’s valid for v1.0 (it’s also applicable to v1.1. But the one who wants to see it will need to workaround the bugs N2 and N3 first).

The GUI (CSSDT.exe) stores the settings to "HKLM\SOFTWARE\Corsair\Corsair SSD Toolbox\TRIMSchedule" (version 1.0 of Toolbox)

or to "HKCU\SOFTWARE\Corsair\Corsair SSD Toolbox\1.1\SSDToolSchedule (version 1.1 of Toolbox)

The settings are:

DeviceID     – ID of the your SSD drive;
Enabled      - 0 or 1; 1 means that the schedule is enabled;
LastExec     – the time of last execution. It’s Unix time ("number of seconds that have elapsed since 00:00:00 UTC, Thursday, 1 January 1970").
ScheduleData – the time scheduled to run TRIM. The number means "seconds passed from midnight". In example, 3600 means 01:00 a.m., 36000 means 10:00 a.m. etc.
ScheduleType - the type of schedule (daily / each Monday etc.). 1 means "daily".

4.1.) When Toolbox runs the TRIM (if you press the button in GUI or if you set up a schedule to be executed by service in a background) it sets "LastExec" to the current time in Unix format.

Here is the real-life example:

http://thumbnails112.imagebam.com/30244/3efcaf302434261.jpg

4.2.) On other hand, if LastExec > 300 (means 300 seconds or 15 minutes) the scheduled task will not be executed second/third/etc. time

Please, don’t ask _me_ why it works like that. I can imagine the reason(s). But it’s up to the guys from Corsair / LC Tech to explain the logic (for example, how the software handles the task which has been "missed") and the logical mistakes made in Toolbox

So,

the condition is always true (LastExec > 15 minutes).

The task will not run on second/third/forth/etc. day. The schedule will not be shown in GUI anymore.

Please find the screenshots attached:

http://thumbnails111.imagebam.com/30244/2ea58e302434262.jpg http://thumbnails110.imagebam.com/30244/08f5f8302434263.jpg

5th and the last)

There are some more bugs and features (both in logic and implementation of a "scheduler").

But (believe me or not) it does not bring any pleasure to dig into this stuff more than you have to.

I was forced to make it working (you can find the details there). That was the only reason why I learned some aspects of its implementation.

Thanks for the reports. I've passed them on.

Please pass along this to your engineers, as well:

When Corsair creates a background service that is always running for an event that happens rarely (even once a day is a rarity in terms of CPU cycles), it's a plain waste of my computer's resources. That my computer has plenty to spare is besides the point -- bloatware like this is one of the reasons modern computers get bogged down.

There is already a service cooked right into Windows that is specifically for the starting and stopping of tasks: the Task Scheduler.

Your software should not need an always running service for it a TRIM schedule. Just engineer it to integrate with the Windows Task Scheduler, and you no longer have to worry about the issues inside your services scheduling. Abandon them as a bad idea, and use the already provided system, which is far more flexible and powerful, instead.

I appreciate the tips. From what you've suggested, I'm thinking I need to do this:

Task #1 (which is scheduled for once/week)

a) reset LastExec to 0

b) net start CorsairSSDToolBox

Task #2 (which triggers on an Event Log entry that the TRIM job completed.)

a) net stop CorsairSSDToolBox

This way, the service is not running when it doesn't have anything to do.

I'll report back once I've had time to implement and test.

Thanks again for the help.

Hello ltwally

 

The issue looks similar to the below described bug N4.

There could be quite a lot of workarounds.

 

1.) Example 1.

The simplest way which comes in mind is to reset the LastExec to 0 every time (let’s say daily) when you need to run TRIM.

It could be something like this:

- send "pause” command to the service (net pause CorsairSSDToolBox):

- reset "LastExec" to 0 (reg.exe add "KeyGoesHere" /v "LastExec" /t reg_dword /d 0 /f);

- send "continue” command to the service (net continue CorsairSSDToolBox)

 

2.) Example 2.

This example uses slightly different approach. It does not rely on scheduler of Toolbox. It writes its own schedule to registry and asks the service to do its job.

The routine could look like this:

- stop/pause the service;

- set "ScheduleData" to current time (number of seconds passed from midnight. It could be the current time minus some seconds) and reset LastExec to 0;

- start/continue the service. It will start to TRIM immediately.

 

You can use this command line tool (you can also find different tool or write our own script) to get the number of seconds passed from midnight:

times (link1; link2).

 

Remarks:

1.) Please note that the value of DeviceID must be valid (it contains the version of firmware. So you should update your workaround each time when firmware is updated).

2.) More detailed description goes below.

The GUI (CSSDT.exe) stores the settings to "HKLM\SOFTWARE\Corsair\Corsair SSD Toolbox\TRIMSchedule" (version 1.0 of Toolbox)

or to "HKCU\SOFTWARE\Corsair\Corsair SSD Toolbox\1.1\SSDToolSchedule (version 1.1 of Toolbox)

FYI: I am running v1.1, and the key is in HKLM and not HKCU.

Also, for 64-bit users, you have to change it to:

HKLM\SOFTWARE\Wow6432Node\Corsair\Corsair SSD Toolbox\TRIMSchedule\(id of your device)\

Update: This is under Windows 7 SP1 x64

Task #1 (which is scheduled for once/week)... Task #2 (which triggers on an Event Log entry that the TRIM job completed.)

A.) In this case you would need to keep 2 schedules (the 1st one is defined in Windows task scheduler, the 2nd is configured in CSSDT).

As for me i would prefer to keep/configure it in one place.

I didn't rely on a "scheduler" of Toolbox and wrote to ScheduleData "directly" by means of batch function

:: ----------------------------------------------------------------------------------------------
:: Description  : returns the number of seconds passed from midnight _MINUS_ some seconds
::                (see c_MINUS_SECONDS)
:: Arguments    : %1 - ByReference lngOut [out] - number of seconds passed from midnight
:: Author       : it's nearly a copy-paste from ss64.com ("GetTime.cmd")
:: ----------------------------------------------------------------------------------------------
:fun_TimeGetSecFromMidnight
(SetLocal)
::
(Set c_MINUS_SECONDS=2)
:: ----------------------------------------------------------
::
:: ---extract the delimiters-----------
(For /f "tokens=1-3 delims=1234567890 " %%J In ("%time%") Do (Set "strDelims=%%J%%K%%L"))
:: ---get hh,mm,ss---------------------
(For /f "tokens=1-3 delims=%strDelims%" %%G in ("%time%") Do ((Set strH=%%G) & (Set strM=%%H) & (Set strS=%%I)))
::
:: ---strip leading space--------------
:: (includes workaround for 08 and 09)
(Set /A "lngSeconds=%strH: =% *3600 + 1%strM%*60 - 6000 + 1%strS% - 100 - %c_MINUS_SECONDS%")
::
:: ---workaround for ~00:00------------
(If %lngSeconds% LSS 1 (Set lngSeconds=1))
::
(EndLocal) & (Set %1=%lngSeconds%)
(Goto :Eof)
:: ----------------------------------------------------------------------------------------------

Usage example:

(Call :fun_TimeGetSecFromMidnight lngSchedData)
(Echo debug: the new value of ScheduleData is [%lngSchedData%])
(reg.exe add "KeyGoesHere" /v "ScheduleData" /t reg_sz /d %lngSchedData% /f>NUL)

Remark: the function assumes the date to be in hh:mm:ss format.

...Task #2 (which triggers on an Event Log entry that the TRIM job completed.)

B.) It would be a good idea but the service does not write anything to Event Log in case of success (on Windows XP at least) : (

That was the reason why i used a routine which monitors a size of cssdt.log (the one created/written from a service). I would not call it a reliable way but it works :sigh!:

C.) The service writes a "Warning" to Event Logs when it's stopped (the number of 'warnings' corresponds to the amount of TRIMs done)

Here is a screenshot:

http://thumbnails110.imagebam.com/30304/93d94a303034708.jpg

These "warning" doesn't make sense in case of Neutron series (LAMD-based). It takes only some seconds to send a banch of TRIMs (see cssdt.log) .

So i do not see any reasons to flag this situation as something "abnormal" (i'm talking about Neutron series. I have not tested this behavior on SF-based drives).

B.) It would be a good idea but the service does not write anything to Event Log in case of success (on Windows XP at least) : (

That was the reason why i used a routine which monitors a size of cssdt.log (the one created/written from a service). I would not call it a reliable way but it works :sigh!:

Yes, I discovered that as I was creating my Task Scheduler entries..

What I ended up doing was setting the second task to trigger 15 minutes after the first. Hopefully that is sufficient time for a weekly TRIM job on a lightly used Neutron GTX.

As an aside, does anyone know if there is anything else that the CorsairSSDToolbox service does, beyond the scheduled TRIM job?

FYI: I am running v1.1, and the key is in HKLM and not HKCU.

 

Also, for 64-bit users, you have to change it to:

HKLM\SOFTWARE\Wow6432Node\Corsair\Corsair SSD Toolbox\TRIMSchedule\(id of your device)\

 

Update: This is under Windows 7 SP1 x64

Hello ltwally,

i have re-checked the settings of v1.1 on XP and on 7x64.

i think it's just a leftover from v1.0. It has nothing to do with v1.1

As an aside, does anyone know if there is anything else that the CorsairSSDToolbox service does, beyond the scheduled TRIM job?

I think there is nothing more at the moment.

(Theoretically) it is possible to use the service for

- polling for firmware updates. I'm not completely sure if it's worth the efforts (firmware updates are released once in... i do not know indeed, but it happens not every month);

- polling the SMART attributes (looks like the functionality is not yet completed in v1.1. There could be also other reasons not to release it)

By the way,

you could take a short trip to the past and to the future by googl-ing for 'Solid State Doctor'. It could be quite interesting but definitely would not be so helpful: the most of bugs are still here (this is quite logical indeed).

But seriously...

I would not blame the guys from Corsair so much for these bugs (with the exception of bug N3 and N4 :roll:).

But the product is named Corsair.

I am quite satisfied by the quality of hardware. I do believe that the software must be of adequate quality as well.