I posted this in the hardware section but not getting any responses.
 
I had a previous post about this problem and thought it was resolved, but its not. 
If I power on my equipment rack, which includes the X-Touch (and its shown as working OK in the Device Manager) and then start Sonar Plat or the newer CbB the X-Touch is shown, correctly, as a control surface BUT apparently Sonar is not communicating with the X-Touch as the motorized faders are not working and the track indicators/switches do not work.  This appears to be a Sonar/CbB problem as I can start Studio One 3 or Cubase LE and the X-Touch is working OK with them.  
 
I can get Sonar/CbB to communicate with the X-Touch by deleting the X-Touch and adding a new control surface, Mackie Control.  After the delete/add the X-Touch works in Sonar/CbB.
 
The X-Touch and Sonar has worked properly for a long time.  The problem has been going on for a couple of months and I would suspect some Windows 10 update is causing the error in Sonar.  Something that has been heavily discussed here, a Windows update "breaking" Sonar.  CbB appears to be basically a rebadged Platinum version and most likely why Platinum and CbB both have the problem.

I have the latest Windows 10 Pro, Version 1709 Build 16299.371 and a dual boot Windows Insider V 1803 (a very minimal install on the Insider version - the OS, MS Office and Sonar Platinum/CbB).  It acts the same on both.

For what it's worth, I have been using X-Touch with SPLAT, and CbB, since it's release, with no problems. However, I'm still running Win7, so can't speak to Win10.
 
With so much talk of Win10 updates breaking things, makes me reluctant to change.
Sorry, this of course doesn't address your problem, but maybe this reinforces the idea that perhaps Win10 is the problem, and not CbB. 

My X-Touch worked for a long time (I don't remember when I got it but at least 2 years ago). Then the problem started.  It could very well be a Windows update but Studio One 3 and Cubase LE do not have the problem.  Only Sonar/CbB has the problem.  

Where is "Azslow"?? 

fireberd
Where is "Azslow"??

I am here. But I can not add much to what I have already written before:
* Sonar/CbB identify MIDI devices by names and tries to match these strings to what Windows return. The list is saved in %APPDATA%\Cakewalk\<Sonar version>\TTSSEQ.INI
When something is wrong here, the file should be deleted.
 
* Sonar 2017+ has introduced a bug in the matching system. As the result, even when "Control Surfaces" preferences show correct ports, in practice Sonar can use other (wrong) ports to communicate with the device.
That happens when TTSSEQ.INI information can not be matched with Windows information correctly, which in turn happens when:
1) in Windows Device manager, MIDI section, there are "bad" devices. The whole list can be seen only with "list not connected devices option". It is better to remove all orphan entries and in case active device is not "1", delete and reinstall it (f.e. reconnected to different port, physically or logically, leaving orphan entry as "1" and thinking it is not the first such device in the system)
2) there are devices which are not always connected when Sonar starts (sometimes that is ok, sometimes not). For troubleshooting, all MIDI devices mentioned in the Device Manager should be connected every time Sonar starts.
3) (any) device randomly "re-connects", f.e. with USB power management enabled, bad cables, bad USB hubs, etc. Can be observed keeping the Device Manager running, it visually "updates" the whole list where some changes are spotted. Alternatively can be seen in logs (more tricky to find).  USB power management should be switched off for all music devices, most of them glitch with this setting on.
 
* original Mackie Control plug-in requires 2 way communication present and working, it is stuck in "Connecting..." otherwise. My mod of this plug-in has "Disable handshake" option. That allows to check the Input from MCU (compatible) device is working, even in case the output is wrong. It also adds ProChannel EQ/Comp support and a workaround against Sonar crash in case MCU tries to control ProChannel Compressor (bug in Sonar).
 
So, brute-force way:
* delete TTSEQ.INI
* delete all MIDI devices in the Device Manager (including hidden!)
* switch off the computer
 
Then, for testing, every time boot the computer only AFTER all MIDI devices are powered and switch them off only after the computer is switched off. Do not put the computer into sleep. Check that in such case everything is always stable. If it is, try to add "features" one by one (f.e. sleep/wake, turning the rack on/off when computer is working, etc.), several times checking that things are still working. Till the reason is found...
 

Thanks for the info on the TTSSEQ.INI.  I'll try that first. 
I've tried the delete all MIDI devices and that never helped.
 

i'm surprised to hear they use string comparisons of device names

Deleting all the TSSEQ entries did not help. 
When I opened Sonar, the X-Touch was listed but not selected as a MIDI Device.  However,  it was still shown as a control surface.  I still had to delete and re-add the Mackie to make it work in Sonar.
 
 

When you delete TTSSEQ.INI, you delete MIDI configuration in Sonar. So you have to enable MIDI IO again and assign ports to surfaces. Note that you can change ports of MackieControl, I mean without remove/add procedure.
The question is how stable it is, I mean:
* you delete TTSSEQ.INI, start Sonar, enable MIDI IO, assign to MackieControl, X-Touch works.
* you stop Sonar, start Sonar again: is X-Touch still working?
* if yes, you reboot the computer, start Sonar: is X-Touch still working?
* if yes, you stop Sonar, switch off the Rack, switch on the Rack, start Sonar: is X-Touch still working?
* if yes, you stop Sonar, wait 1 hour, start Sonar: is X-Touch still working?
I mean we should identify what is triggering the bug in Sonar (no question that is a bug, but it is usually ineffective).
 
Different question: which MIDI mode you are using in Sonar? They have recently added second mode... 

pwalpwal
i'm surprised to hear they use string comparisons of device names

They are using the same in Project files. But that was also never working as soon as something is changed. They have tried to improve, in project files and in Sonar, with the result they have made it worse in Sonar and still nothing works for projects. I have hard time to believe they do not know what they are doing, but the result looks exactly like that is the case...
In projects that can be problematic, if the engine does not support re-appeared MIDI devices on the fly that is hard to add correctly. But simple MIDI device list is too simple to make any mistake. Till they have a bug in corresponding list enumeration (from other users observation, Sonar in fact "shift" devices in the list by one).