You are not logged in.
Pages: 1
Today we deployed an update to our client application, which uses mORMot v2.4.
Several Windows 10 users reported an Access Violation error (the typical "Access violation at address aaaaaa in module bbbbb (offset cccccc). Read of address dddddd.").
I reproduced the issue on a Windows 10 VM. I also tested the application after reverting to mORMot v2.3, and the error no longer occurs with that version.
On Windows 7 and Windows 11, the application works without any issues.
Unfortunately, I don't have access to a Windows 10 dev machine to debug this further.
Offline
If some of your clients still use Windows 10, you need to have a VM with Windows 10 for testing your app, for sure.
There could be a lot of reasons for this, potentially not part of mORMot itself.
Especially since you are the only one reporting such an issue with Windows 10.
Without any more information, difficult to understand what happens.
The regression tests did pass with no issue on Windows 10 e.g. tonight:
https://luti.tranquil.it/get_folder_res … 93aW5kb3dz
Offline
While trying to set up remote debugging, I disabled Optimization in the project options - Building > Delphi Compiler > Compiling, and now the application works without any issues on Windows 10.
Very strange.
Offline
I found that the Access violation on mORMot 2.4 actually happened on more windows versions (Windows 7, Windows 10 and Windows 11 ARM) depending on the Optimization being on or off.
On some windows versions it happens when Optimization is on, on others when it is off...
After a couple hours of not being able to do remote debugging on the specific application/system where the error happens (I can do remote debugging on a simple app, but not on our main app, I don't know why) I turned to rudimental debugging mode (using showMessage('test 01') on suspicious lines to try to pinpoint the line where the error happens lool. Yeah, I know...
But I did eventually found something that I think maybe is a clue for you guys to fix the root cause of this strange problem.
I added "Application.processMessages" to mORMot's ClientSetUser function and this fixes the problem in almost every windows version, unfortunately, with this line added the error started to happen on some Windows 11 x64 machines... So... not a 100% fix. We did end up removing this fix because we cannot predict the machines it will affect, and there are far more Windows 11 x64 machines then older Windows versions on our client base.
Adding "Application.processMessages" would never be a final fix of course.
I was using showMessage to find the line where the error happens... But I noticed that using showMessage in certain places caused the error not to happen...
I then used Application.processMessages insted of showMessage for a silent solution...
I'm available to test on my specific app if there is something to this and you need some testers.
Last edited by imperyal (2026-08-21 18:02:15)
Offline
adding ShowMessage and ProcessMessages to multi-thread cross-platform framework is like one thread says "hold my beer" to other threads until i do my thing. imo don't use ProcessMessages at all and use ConsoleWrite or TSynLog library instead of Vcl heavy ShowMessage for getting outputs.
Last edited by koraycayiroglu (2026-08-22 08:20:47)
Offline
1) mORmot has great logging features. use it to circumvent the issue e.g. with the stack trace of the GPF
2) call AllocConsole then some writeln or mormot ConsoleWrite() if you want some real time output
3) it is very likely that the error is in your own code - ask an AI engine to verify your code
Offline
Ok. After adding some logging and stack tracing, and with some help from AI, this is what I found:
On the log file:
0000000000000d64 ! EXCOS EAccessViolation (c0000005 EXCEPTION_ACCESS_VIOLATION) [Main] at 02666302 mormot.rest.client.pas TRestClientAuthenticationDefault.ClientComputeSessionKey (1402) {2 0.24 0.68 0.9GB/6GB 1db10b01}
00000000000d455f ! ERROR ERROR: {"EAccessViolation(0d30dff0)":{Message:"Access violation at address 02666302 in module 'Horarios.exe' (offset 1606302). Read of address 0000000B"}} mormot.core.log.pas TSynLog.LogInternalFmt (6000) mormot.core.log.pas TSynLog.Log (5303) U_data.pas tTablesServer.user_loginOk (4121) U_login.pas TFRM_login.processLogin (357) U_login.pas TFRM_login.BUT_okClick (679) TControl.Click cxButtons.pas TcxCustomButton.MouseUp (2221) TControl.DoMouseUp TWinControl.WndProc TButtonControl.WndProc TWinControl.MainWndProc StdWndProc
00000000000d491f ! EXCOS EAccessViolation (c0000005 EXCEPTION_ACCESS_VIOLATION) [Main] at 02666302 mormot.rest.client.pas TRestClientAuthenticationDefault.ClientComputeSessionKey (1402) mormot.rest.client.pas TRestClientAuthentication.ClientSetUser (1331) mormot.rest.client.pas TRestClientUri.SetUser (2957) U_data.pas tTablesServer.user_loginOk (4116) U_login.pas TFRM_login.processLogin (357) U_login.pas TFRM_login.BUT_okClick (679) TControl.Click cxButtons.pas TcxCustomButton.MouseUp (2221) TControl.DoMouseUp TWinControl.WndProc TButtonControl.WndProc TWinControl.MainWndProc StdWndProc {2 0.24 0.68 0.9GB/6GB 1db10b01}Fix proposal / hint:
I highlighted the fix and the line where the error occurs with //########
class function TRestClientAuthenticationDefault.ClientComputeSessionKey(
Sender: TRestClientUri; User: TAuthUser): RawUtf8;
var
resp, mcfhash, servernonce, clientnonce, proof: RawUtf8;
clientsign: THash256;
rnd: THash128 absolute clientsign;
values: array[0..1] of TValuePUtf8Char;
begin
result := ''; // error
if User.LogonName = '' then
exit;
FillChar(values, SizeOf(values), 0); //######## FIX
// compute the 160-bit client nonce (needed by ScramClientProof)
Random128(@rnd); // unpredictable
Join([CardinalToHex(OSVersionInt32), '_', BinToHexLower(@rnd, SizeOf(rnd))],
clientnonce);
// try "mcf" for servers with "Modular Crypt" support
if (User.PasswordHashHexa <> '') and
(User.Data = 'mcf') then // passModularCrypt flag with clear/plain password
begin
User.Data := '';
Sender.CallBackGet('auth', ['username', User.LogonName, 'mcf', 1], resp);
JsonDecode(resp, ['result', 'mcf'], @values);
values[0].ToUtf8(servernonce);
if servernonce = '' then
exit;
// hash the password, with proper "Modular Crypt" support
if values[1].Text <> nil then // this user got a mcf specific format
mcfhash := ModularCryptHash(values[1].ToUtf8, User.PasswordHashHexa);
if mcfhash <> '' then
if values[1].Text^ = '$' then
// no mutual auth - regular mORMot 1 hashing
User.PasswordHashHexa := mcfhash
else
// SCRAM-like mutual authentication with irreversible proofs
proof := ScramClientProof(mcfhash, User.LogonName, clientsign,
// match ScramServerProof() msg parameters
[Sender.fModel.Root, servernonce, clientnonce, User.LogonName])
else
User.SetPassword(User.PasswordHashHexa, ''); // fallback to old hash
end
else
// regular authentication with User.PasswordHashHexa = hashed value
servernonce := Sender.CallBackGetResult('auth', ['username', User.LogonName]);
if servernonce = '' then
exit;
// compute and return a proof, challenged against client and server nonces
if proof = '' then
// regular mORMot 1 authentication via simple hexadecimal hashing
proof := Sha256U([Sender.fModel.Root, servernonce, clientnonce,
User.LogonName, User.PasswordHashHexa]);
result := ClientGetSessionKey(Sender, User, [
'username', User.LogonName,
'password', proof,
'clientnonce', clientnonce]);
// now result <> '' contains 'id-privatekey' on authentication success
if (values[1].Text <> nil) and //######## ERROR: EAccessViolation - depending on Optimization and Windows version
(values[1].Text^ = '#') then
// authenticate the SCRAM server from the returned proof
if result = '' then
User.PasswordHashHexa := ''
else if ScramClientServerAuth(mcfhash, User.LogonName,
Sender.fSession.ScramServerProof, clientsign) then
// success: fSession.PrivateKey computed without the server DB key
User.PasswordHashHexa := '#'
else
result := ''; // error
end;Offline
Now I understand the problem.
With the stack trace, it helped a lot indeed.
Please check with
https://github.com/synopse/mORMot2/commit/f674c4858
Sorry for the long inconvenience.
Offline
Pages: 1