Calibre not starting (Windows 10)

[MINGXXIIE]

Hi,

First off, apologies if this is the wrong place to post, I've used Calibre for years but never really got round to joining the forums. I have an issue with Calibre starting.

When I install Calibre (64bit) and launch the program, I get the usual splash screen, but once Calibre says "Starting User Interface", the program simply quits with no error message.

I ran

calibre-debug -g

in a cmd console, and this is the output I got:

calibre 3.32 [64bit]  embedded-python: True is64bit: True
Windows-10-10.0.17134-SP0 Windows ('64bit', 'WindowsPE')
('Windows', '10', '10.0.17134')
Python 2.7.12+
Windows: ('10', '10.0.17134', 'SP0', u'Multiprocessor Free')
Interface language: None
Turning on automatic hidpi scaling
devicePixelRatio: 1.0
logicalDpi: 96.0 x 96.0
physicalDpi: 135.5328125 x 135.466666667
Using calibre Qt style: True
[0.00] Starting up...
[0.02] Showing splash screen...
[0.12] splash screen shown
[0.12] Initializing db...
[0.14] db initialized
[0.14] Constructing main UI...

and that's it... I can't figure out the problem. Also, if I may note, I'm using a Lenovo Yoga 330 11

Hope someone knows what's going on

Thanks, Ming

[kovidgoyal]

Did you connect an external montior/tv recently? If so calibre might be starting off screen. IIRC there is a windows command you can use to gather all windows ont the current screen.

[MINGXXIIE]

Originally Posted by kovidgoyal

Did you connect an external montior/tv recently? If so calibre might be starting off screen. IIRC there is a windows command you can use to gather all windows ont the current screen.

Not really. I don't think that is the issue as Calibre doesn't even show up as a process in Task Manager. It just quits

PS: Near-instant response from the creator of Calibre! I'm honoured

[DaltonST]

I'm using a Lenovo Yoga 330 11

I have several Windows tablets, including a new Win10 2-in-1 tablet built in Shenzhen (China), and I have had problems with that one identical to your issue with your Lenovo. This is what I have done (and am doing) to resolve them:

[0] Using keys Windows+R: control userpasswords2 and assign yourself using the bottom radio button to the Administrators Group. Yes, you already are, but do it anyway. Apply the setting, and then restart your PC.

[1] "Take Ownership" of every root directory on every drive on the PC. See the attached .zip file.

[2] Change Security Permissions for every root directory on every drive on the PC, including all of their subdirectories, to add your User Name as having "Full Control". Ditto for the Administrators Group and also SYSTEM.

[3] Take Ownership of every newly downloaded Calibre .msi file (and all other downloaded .msi and .exe installation files) before running them. Always Run As Administrator.

[4] When you execute the Calibre .msi file, it might fail due to permissions to update the Windows System Menu directory when it tries to install a shortcut in the Menu, and then reverse the entire installation just for that minor feature. Very tedious. So, simply change the original install options to not install a shortcut in the Menu.

[5] Originally, I got Calibre Portable to work installed on a partition, Drive D. Then, using the above steps, I got Calibre 64 to install on Drive C. I specified in the Environment Variables (Control Panel > System > Advanced System Settings > Environment Variables) to use the Settings directory of the Drive D Portable installation for the Calibre configuration. CALIBRE_CONFIG_DIRECTORY.

[6] Calibre had issues not being able to use C:\Windows\Temp as the directory for temporary files, so I also changed CALIBRE_TEMP_DIRECTORY to C:\Temp. Which of course I took full control and ownership of as described above. I then set CCleaner to clean that particular directory at Startup.

It should not be this hard. If I had it to do over, I would have bought a 2-in-1 tablet manufactured elsewhere based on the assumption that my tablet's manufacturer botched its OEM-modified version of Win10 that it routinely installs.


Good luck.



DaltonST

[MINGXXIIE]

My gosh.

It really shouldn't be this hard to get things working. Had I known this I'd have just gotten a normal (non touch) laptop. Hope the developers see this and fix it - I know this is an open source app and most people work on this in their free time, but most Windows laptops are soon going to have touchscreens, and I'm sure this problem will soon be replicated somewhere else.

That being said, thanks for the help, I'll try your suggestions and see if it works!

[theducks]

I don't think you are the only user with a touch screen. Those others are working just fine (Kovid did some touch support work a loooong time ago)

[MINGXXIIE]

I just did everything DaltonST said, short of reinstalling Calibre. Gave up in the end

I think I'll just use Calibre on my desktop (and sync my Kindle from there). Thanks for the help everyone!

PS: Would you guys think it has something to do with the CPU I'm running? Because it's a very new CPU, the Intel Pentium Silver N5000. Apart from that and the touch screen (it is a Yoga, after all), I can't think of anything else that would cause the issue.

- Ming

[Sirtel]

Originally Posted by theducks

I don't think you are the only user with a touch screen. Those others are working just fine (Kovid did some touch support work a loooong time ago)

Yes indeed. I also have a Lenovo Yoga 2-in-1 convertible with Windows 10 and there hasn't been a single problem with Calibre. The same goes for my Surface tablet with Windows 10, Calibre runs without any problems.

Unfortunately I cannot offer any suggestions to the OP.

[kovidgoyal]

I highly doubt this has anything to do with touch screens. Most liekly some program is interfering with calibre. Run windows in safe mode and see if calibre works then, to test that.

[MINGXXIIE]

Just tested in safe mode. Still the same issue. Using

calibre-debug -g

gives the same output - where the program just exits right after

[0.30] Constructing main UI...

If it helps, I've dumped my entire system log into an NFO file (attached in post). Note that this NFO dump was taken while in Safe Mode, and under the error logs, Calibre is listed twice (with errors I don't understand, I'm sure you guys do hahah)

Hope to hear from you all soon. Once again, thanks very much!

- Ming

[kovidgoyal]

that log shows the crash is in the ssl.pyd module, which is a module used to connect to https servers. SSL on windows systems is often interefered with by malware/spyware, which is likely the cause of the crash. Sadly, I dont know of a good way to fix that, short of re-installing the system from a known clean windows image.

So your options are either:

1) use calibre onyour desktop
2) re-install with a clean windows image

I'd strongly recommend (2) since there is a chance you have malware on your system, but it might be too much effort. The choice is yours.

[MINGXXIIE]

Aw man, malware? I just reinstalled Windows barely 2 weeks ago, but given your suggestion perhaps I'll do it again. Not much effort as most of my files are in the cloud anyway.

Thanks for the help!

PS: If my university wasn't so reliant on Microsoft Office, I'd jump ship to Linux almost instantly.

[DiapDealer]

We (Sigil) had an issue on Windows with Qt5 trying to load incompatible versions of openssl dlls that other programs had put on the system PATH. It kept Sigil from starting. But we weren't including our own openssl dlls in the same directory as the Qt5 dlls, either. So the same thing shouldn't plague calibre. But I thought I'd mention it anyway.

Perhaps some profiling with Dependency Walker would reveal something?

[kovidgoyal]

I doubt it's incompatible openssl dlls. calibre injects the calibre dll folder into the dll load order using SetDllDirectory to ensure that the bundled dlls are used in preference to any in PATH. See https://docs.microsoft.com/en-us/win...tdlldirectorya

In my experience, crashes in ssl modules are caused by software trying to hook ssl related system calls to intercept them.

[DiapDealer]

Originally Posted by kovidgoyal

I doubt it's incompatible openssl dlls. calibre injects the calibre dll folder into the dll load order using SetDllDirectory to ensure that the bundled dlls are used in preference to any in PATH. See https://docs.microsoft.com/en-us/win...tdlldirectorya.

I knew it wasn't likely to be an issue with calibre. It just seemed similar.