mORMot 2.4 - Windows 10 Error

imperyal · 2026-07-02 12:18:26

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.

ab · 2026-07-02 13:43:53

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

imperyal · 2026-07-03 15:08:30

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.

imperyal · Today 17:46:00

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...

class function TRestClientAuthentication.ClientSetUser(
  Sender: TRestClientUri; const aUserName, aPassword: RawUtf8;
  aPasswordKind: TRestClientSetUserPassword; const aHashSalt: RawUtf8;
  aHashRound: integer; aDigestAlgo: TDigestAlgo): boolean;
var
  U: TAuthUser;
  key: RawUtf8;
begin
  result := false;
  if Sender <> nil then
  try
    Sender.SessionClose;  // ensure Sender.SessionUser=nil
    U := TAuthUser(Sender.fModel.GetTableInherited(TAuthUser).Create);

    // #######################
    Application.ProcessMessages;    // Line added
    // #######################

    try
      U.LogonName := TrimU(aUserName);
      U.DisplayName := U.LogonName;
      if aPasswordKind = passModularCrypt then
        U.Data := 'mcf'; // notify ask for the server for the "mcf" format
      if aPasswordKind = passClear then
      begin
        if aDigestAlgo <> daUndefined then
          aHashRound := -ord(aDigestalgo);
        // compute with SHA-256, Pbkdf2HmacSha256() or DIGEST-HA0 hash
        U.SetPassword(aPassword, aHashSalt, aHashRound);
      end
      else
        // passHashed, passKerberosSpn, passModularCrypt: already prepared
        U.PasswordHashHexa := aPassword;
      key := ClientComputeSessionKey(Sender, U); // overriden with algo
      result := Sender.SessionCreate(self, U, key);
    finally
      U.Free;
    end;
  finally
    if Assigned(Sender.OnSetUser) then
      // always notify of user change, even if failed
      Sender.OnSetUser(Sender);
  end;
end;

I'm available to test on my specific app if there is something to this and you need some testers.

Last edited by imperyal (Today 18:02:15)

mORMot Open Source

#1 2026-07-02 12:18:26

mORMot 2.4 - Windows 10 Error

#2 2026-07-02 13:43:53

Re: mORMot 2.4 - Windows 10 Error

#3 2026-07-03 15:08:30

Re: mORMot 2.4 - Windows 10 Error

#4 Today 17:46:00

Re: mORMot 2.4 - Windows 10 Error

Board footer