Program crashes on Windows 11 within Try Except

[gicla]

Hi everybody,

After days trying to understand I decided to post here as I'm lost.
My program always ran fine on Windows10. Since a few months I upgraded to Windows 11 and now at all the Try...Except, in cas of errors it freezes instead of executing the Except clause.
Any hint please?

That's the code which hangs:

Code: Pascal  [Select][+][-]

1.   // Verify Fields value type for M fields and MF or MD whitin approved messages
2.         case UpperCase(copy(aFieldsDef[3, z], 1, 3)) of
3.           'INT' : begin
4.                     try
5.                       iTestValue := StrToInt64(AnsiString(xmlDoc.DocumentElement.FindNode(aFieldsDef[1, z]).TextContent));
6.                     except
7.                       WriteError('Line: ' + sLine + ' | ' + xmlStr.DataString, 'ERROR: "' + AnsiString(aFieldsDef[1, z]) + '" value MUST be numeric, only digits allowed here.');
8.                     end;
9.                   end;
10.           'STR' : begin
11.  
12.                   end;
13.           'CON' : begin     { TODO : da eliminare e gestire }
14.  
15.                   end;
16.           else MessageDlg('(' + AnsiString(sMsgType) + ') ' + AnsiString(aFieldsDef[1, z]) + ' - Wrong field type definition ' + '(' + UpperCase(copy(aFieldsDef[3, z],1,3)) + ')' + ' into the ini file.' + #10 + 'Allowed values are:' + #10 + '"STR" = String' + #10 + '"INT" = Numeric', mtWarning, [mbOK], 0);
17.         end;
18.  

I tried to inser the following test code in teh same procedure which hangs and it also hangs:

Code: Pascal  [Select][+][-]

1.   divider := '0';
2.   Try
3.     Result := 5 div StrToInt(divider);
4.   Except
5.     showmessage('0 divide not possible');
6.   end;
7.  

However, the same sample code used in a different procedure, works just fine.

[rvk]

So what does WriteError do?

What happens if there is an exception in your except clause?

What happens after this code?

Just change the writeerror to

Code: Pascal  [Select][+][-]

1. on E: exception do showmessage(e.message);

and you'll see the actual reason for the exception.
(Or run in the IDE and let it catch the exception)

[Thaddy]

Note EDivideByZero is one of the standard exceptions defined in sysutils.ou do noy want to rely on sysutils, because of its size, you can check for error 200.

[PascalDragon]

Note EDivideByZero is one of the standard exceptions defined in sysutils.ou do noy want to rely on sysutils, because of its size, you can check for error 200.

On Windows with SEH using try … except-blocks without using the SysUtils unit is currently (from 3.2.0 on) not fully supported anymore, because the SEH implementation is missing some functions to allow the usage without that unit.

[Bart]

On Windows with SEH using try … except-blocks without using the SysUtils unit is currently (from 3.2.0 on) not fully supported anymore, because the SEH implementation is missing some functions to allow the usage without that unit.

Is that documented somewhere?

Bart

[dbannon]

On Windows with SEH using try … except-blocks without using the SysUtils unit is currently (from 3.2.0 on) not fully supported anymore, because the SEH implementation is missing some functions to allow the usage without that unit.

Wow, that rings alarm bells, especially for Windows avoiders like me. SEH is a compiler option to Microsoft C (and incomplete with C++), so a FPC/Lazarus app would not be using SEH. Even MS seem to suggest its not a good thing. Is the warning from Pascal Dragon because we might be linked to libraries that do use SEH ?

By " not fully supported" do you mean it compiles but might not work ?  Does the compiler generate a Warning for example ?  Given that I do much of my "What if this happens" extreame testing in Linux, sounds like the exceptional events that might lead to an Exception might just crash my app on Windows unpredictably ?

Worried from Axedale
(Davo)

[avra]

That's the code which hangs:

If you delete line 16 does it still hang?

[ASerge]

Code uses Dialogs.MessageDlg. Unit Dialogs include SysUtils, therefore, thoughts about the fact that SEH does not work without Sysutils in this topic can be discarded.
We need a minimal example of where the error would occur so that others can check it. Maybe the problem is elsewhere.

[PascalDragon]

On Windows with SEH using try … except-blocks without using the SysUtils unit is currently (from 3.2.0 on) not fully supported anymore, because the SEH implementation is missing some functions to allow the usage without that unit.

Is that documented somewhere?

No, because it's essentially a bug.

On Windows with SEH using try … except-blocks without using the SysUtils unit is currently (from 3.2.0 on) not fully supported anymore, because the SEH implementation is missing some functions to allow the usage without that unit.

Wow, that rings alarm bells, especially for Windows avoiders like me. SEH is a compiler option to Microsoft C (and incomplete with C++), so a FPC/Lazarus app would not be using SEH. Even MS seem to suggest its not a good thing. Is the warning from Pascal Dragon because we might be linked to libraries that do use SEH ?

Ehm... you are aware that SEH is the exception handling mechanism on Windows, used throughout the operating system and even across languages? The compiler option in MSVC is simply whether the conversion of SEH exceptions to C++ exceptions is enabled.

There's a reason after all that we switched from setjmp/longjmp based exception handling, because otherwise there were issues with exceptions that occurred in libraries that the executable captured while it shouldn't.

By " not fully supported" do you mean it compiles but might not work ?  Does the compiler generate a Warning for example ?  Given that I do much of my "What if this happens" extreame testing in Linux, sounds like the exceptional events that might lead to an Exception might just crash my app on Windows unpredictably ?

It means that it will compile, but an except-block might not be entered correctly if at all if an exception occurs.

[dbannon]

....
Ehm... you are aware that SEH is the exception handling mechanism on Windows, used throughout the operating system and even across languages? The compiler option in MSVC is simply whether the conversion of SEH exceptions to C++ exceptions is enabled.

Nope !  I don't use Windows, I most certainly don't do any low level programming under windows. Thats why I use FPC/Lazarus.

.....
It means that it will compile, but an except-block might not be entered correctly if at all if an exception occurs.

Like I said, Wow.
So, quick grep through my code, only 36 "except on", less than I'd expect. But quite a variety.  Is there any point in testing ?  I mean, if I simulate, say an EXMLReadError and its correctly handled, can I assume it would always be correctly handled ?

David

[gicla]

Thank you all for your time and responses, let me give you some more info below:

@rvk
The "WriteError" procedures works just fine. When the program doesn't hang, due to the try...exept issue, WriteError does what it should do.
When there is an exception, instead of executing the code after "Except", the program hangs displaying the attached error.
If I move the same Try...Except code outside the procedure where it should run, it works as expected executing the "Except" clause .

@ASerge is correct. SysUtils is included

[gicla]

Let me add some additional info which, to me, makes this issue a little weirder:

The following code make the application hanging when executing the "Except" clause:

Code: Pascal  [Select][+][-]

1. procedure TForm1.VerifyMandatoryFields;
2. var
3.   z, x, i, iSLIdx, iDummy : Integer;
4.   iTestValue, Mytest : Int64;
5.   sTmpNodeName : WideString;
6.   sFldDim : String;
7.   bDccChecked : Boolean;
8.   OPIExpDate : TDateTime;
9.   ExRate : Real;
10.   dDummy : Double;
11. begin
12.   try
13.     MyTest := StrToInt64('12z3568');
14.   except
15.     showmessage('Not a valid Int64 value');
16.   end;
17. end;
18.  

While the following code works just fine:

Code: Pascal  [Select][+][-]

1. procedure TForm1.VerifyMandatoryFields;
2. var
3.   z, x, i, iSLIdx, iDummy : Integer;
4.   iTestValue, Mytest : Int64;
5.   sTmpNodeName : WideString;
6.   sFldDim : String;
7.   bDccChecked : Boolean;
8.   OPIExpDate : TDateTime;
9.   ExRate : Real;
10.   dDummy : Double;
11. begin
12.   if not TryStrToInt64('12z3568', Mytest) then showmessage('Not a valid Int64 value');
13. end;

[rvk]

When and by what code is TForm1.VerifyMandatoryFields called?

What happens if you put this code in a Button1Click under a button?
Does it hang then too?

(I'm wondering if this code isn't called sitting a thread or something.)

[gicla]

When and by what code is TForm1.VerifyMandatoryFields called?

What happens if you put this code in a Button1Click under a button?
Does it hang then too?

(I'm wondering if this code isn't called sitting a thread or something.)

TForm1.LoadButtonClick event calls
|
|--> TForm1.AnalyzeLog which in turn calls
                        |
                        |--> TForm1.VerifyXMLHeaderExist
                        |--> TForm1.VerifyMandatoryFields

[rvk]

If the code also crashes in a simple ButtonClick then you can make a small project which reproduces the problem and it can be submitted as bugreport.

For me, this works without any problems on Linux Mint.

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   Mytest : Int64;
4. begin
5.   try
6.     MyTest := StrToInt64('12z3568');
7.   except
8.     showmessage('Not a valid Int64 value');
9.   end;
10. end;