Thursday, April 09, 2015
Crashplan saved my life on so many occasions, that I had to work a bit to find and fix a relatively hard to spot error in my setup. It was brought to my attention by the very useful backup mails that my Crashplan hadn't done its job for 3 days. This made me shiver with fear of losing a lot of data - i am a bit paranoid when it comes to data. So I treaded the standard way, close the app, close the computer, restart again etc. When all of this did not work I tried re-installing the software, which did not fix the issue. After searching through the product knowledge base I learned that there are two components of Crashplan: one UI that you and I interract, and one Windows service that does all the background work. UI will give you an error in the line of "Unable to connect to the backup service." Which means the background service is dead. If one types services.msc in the commend prompt (which you can access by writing cmn on the start menu), the service manager of Windows pops up. It was clear that the Crashplan service listed in this window was not running. After manually starting the Crashplan service, the service immediately quits before running. If you search the net for this you will be directed to solutions which lets you play around with the amount of RAM that the service runs, via editing the ini file assciated with the service. Unfortunately, this was not the case for me. So I had to find the log file. Unfortunately, there are many- a log files in Crashplan. One that helped me the most was service.log.0 under C:\ProgramData\CrashPlan\log . After sifting through the log file I came across this line after which there is an exception message: Address already in use: bind, location=[firstname.lastname@example.org:4242], owner=Peer@228159095[email@example.com:4242], com.code42.exception.DebugException: Address already in use: bind, location=[firstname.lastname@example.org:4242], owner=Peer@228159095[email@example.com:4242] com.code42.exception.DebugException: Address already in use: bind, location=[firstname.lastname@example.org:4242], owner=Peer@228159095[email@example.com:4242] Address already in use was the culprit. I know there are many numbers, but what we are looking for is the service in Windows that is listening on port 0.0.0.0:4242, and not allowing Crashplan Service to communicate with the UI component. In oder to find out one has to type netstat -ado in cmd window. This lists all the program-port pairings. I had to find the process ID (PID) of the service or application listening on port 4242. For me the PID associated with this port was 2828, and I was able to kill this process and give my Crashplan service a lifeline with the following order: taskkill /F /PID 2828.