Closed InteXX closed 3 years ago
I am having this problem too since upgrading to 1.60. Error only occurs when autostarting while windows is booting up. My log looks like this:
16:48:55.073 - WhatsappTray::WinMain(): Starting WhatsappTray 1.6.0.0 in Release CompileConfiguration.
16:48:55.075 - WhatsAppApi::Init() - Using leveldb-directory:C:\Users\malte\AppData\Roaming\WhatsApp\IndexedDB\file__0.indexeddb.leveldb\
16:48:55.080 - WhatsappTray::WinMain() - Prepare for starting minimized.
16:48:55.096 - Hook> Attached hook.dll to ProcessID: 0x00002FF4
16:48:55.096 - Hook> Filepath: 'C:\Program Files (x86)\WhatsappTray\WhatsappTray.exe' WhatsappTrayLoadLibraryTest: 'TRUE'
16:48:55.096 - Hook> Detected that this Attache was triggered by LoadLibrary() => Cancel further processing
16:48:55.109 - WhatsappTray::StartWhatsapp() - Starting WhatsApp from canonical-path:'C:\Users\malte\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\WhatsApp\WhatsApp.lnk'
16:48:55.188 - WhatsappTray::StartWhatsapp() - Resolved .lnk (Shortcut) to:'C:\Users\malte\AppData\Local\WhatsApp\WhatsApp.exe'
16:48:57.841 - WhatsappTray::StartWhatsapp() - WaitForInputIdle failed.
16:49:08.136 - WhatsAppApi::IndexedDbChanged() - The logfile has changed
16:49:08.196 - WhatsAppApi::IndexedDbChanged() - file.fail()
True i saw the same thing happening. I need to increase the waittime in the line: auto result = WaitForInputIdle(pi.hProcess, 2000);
This will be included in the next version
@D4koon
Perhaps 3000?
yes something like that
@D4koon
At first I imagined it being configurable, but upon some reflection that seemed a bit much. It's not worth the extra effort.
my workaround is to kill 'whatsapptray.exe' from task manager, leaving running the 'whatsapp.exe' and starting the 'whatsapptray.exe' again. :)
Try this version, i increased the timeout from 2 seconds to 8 seconds WhatsappTrayV1.6.2.1.zip
Btw. @igor-werry WhatsappTray should now kill the old instance when restarting it ;)
@D4koon
The longer timeout seems to be working. Thank you.
WhatsappTray should now kill the old instance when restarting it
Ah, good. That was causing trouble.
I encountered this error at Windows signin today:
Here's the relevant log (with line numbers):
With approximately three seconds elapsing between lines 8 & 10, this appears to be an I/O issue. At Windows signin everything is colliding with everything else as they all rush headlong to be first out of the subway station. WAT/WA ran fine after it all settled down. Here's that log:
For sure it's not a show-stopper. If anything, it's an extremely minor inconvenience. But if I'm correct, perhaps a bit longer wait for results might mitigate the issue?