Mornin.
Hello Brother Rob.
Yeah i suppose that makes sence.
I seem to be having trouble syncing up the windows wallet beyond sept 18. Also i noticed the version 0.17.0.9 crashes upon start sometimes.
Odd part in debug log i saw was :
2021-09-25T06:01:55Z GUI: Platform customization: windows
2021-09-25T06:01:55Z GUI: "ReportInvalidCertificate: Payment server found an invalid certificate: " "79:ad:16:a1:4a:a0:a5:ad:4c:73:58:f4:07:13:2e:65" ("Microsoft Root Certificate Authority") () ()
2021-09-25T06:01:55Z GUI: "ReportInvalidCertificate: Paymen
2021-09-25T06:01:55Z Windows Exception: EXCEPTION_ACCESS_VIOLATION
No debug information available for stacktrace. You should add debug information and then run:
biblepay-qt.exe -printcrashinfo=cfbgsytmmvigc6kdojqxg2cjnztg6aiab5rgsytmmvygc6jnof2c4zlymuwvo2lomrxxo4zaiv4ggzlqoruw63r2ebcvqq2fkbkest2ol5augq2fknjv6vsjj5gecvcjj5haaaa=
Authority 2018") () ()
2021-09-25T06:01:55Z
Anyways after the crash i can just reopen the biblepay-qt and it works , still i have trouble syncing up the wallet.
i have tested from cmd a few times the erasechain=1 command and it tries to resync from zero , but after testing 2 times i noticed it looks like it stops syncing at sept 18. Blocknumber 118074
Gonna do it again and go make some mornin coffe and i post again.
Hey bro Earlz,
So I found a little more info on the Windows crash you had.
(On a side note, creating a debug executable for windows make an EXE file that is over 1 GIGabyte, which is absolutely insane, its so big we cant even package it for a release because it doesnt finish zipping into the installer, so we would have to release the EXE binary naked as a lone download and have people run it manually). But I don't think that will be necessary if we work around the problem with the stack-trace deserializer.
Anyway I ran your stack trace through my windows build (you can do this by running the --printcrashinfo command that it spit out during the crash, and dash-qt takes that hex and deserializes the trace and prints it.
In this case, it looks like its a windows 10 specific issue, something to do with Data Access Prevention (similar to what mac did with gatekeeper) - it keeps monitoring the code to see if it wants to execute any binary instructions at run time outside the scope of the allowed memory; but the problem is for randomx, randomx has a virtual machine that does just that.
And realize we actually call randomx hash functions for every block (even if your not mining) so I can see how this might occur; and I dont think its *every* hash that triggers DEP; I think its more like 1 in 10000 hashes (at least thats what we observed on mac).
So one *possible* solution is to disable DEP or tuen off UAC:
https://www.thewindowsclub.com/exception-access-violation-windows(I still dont have windows 10 here, so I dont know for sure).
I suppose if you want to try it you can at least tell us that if UAC is OFF and DEP is off, if biblepay runs solid for a certain amount of time? Then we can at least be fairly sure it had something to do with that.
And what I can do from my end, is offer a release switch to disable randomx. Note that I do this for MAC, but I dont want to do it for Everyone (because that would impact our security). I would rather it be an obscure feature that makes biblepay into an SPV client...
So let me know if you want to expiriment with that first and if it helps Ill add the disable randomx switch to windows for people who want to run with all the security on (if thats the problem) ...
The randomx virtual machine executes dynamic instructions at run time that It makes up in its own memory space...
Also one other thing we can do once we know its UAC or DEP, is we can reach out to Tevador who supports xmrig, and ask for help, as he might be able to give us a solution that works with windows 10 ; out of curiosity do we need to disable dep and uac on xmrig to mine on windows 10?
Thanks!
Recent Posts