Without any warning, the app built in Lazarus no longer starts.

[dseligo]

I once had similar problem (I don't remember exact error message) because there were no printers installed.
Do you use dll in your program, maybe there is access issue?

[TakamiChie]

Thanks for the reply.

duplicate the project. In the copied project: delete the * .lpi file, delete the resource file. Open your project from Lazarus via * .lpr file.

Perhaps you are lucky and your project will start. Do not forget to re-register the required paths.

What I wrote is not the best solution, but it can be a working way to avoid problems.

Although this was carried out, the place where the error occurred changed, but there was no change in the content of RunError (204).

Code: Text  [Select][+][-]

1. #0 VerifierDisableFaultInjectionExclusionRange at :0
2. #1 ?? at :0
3. #2 ?? at :0
4. #3 ?? at :0
5. #4 ?? at :0
6.  

I once had similar problem (I don't remember exact error message) because there were no printers installed.
Do you use dll in your program, maybe there is access issue?

Certainly calling and using 'AddClipboardFormatListener' and 'RemoveClipboardFormatListener' API of 'user32.dll'.

However, I do not think that it is not installed like the printer.

These codes refer to the forum post below.

https://forum.lazarus.freepascal.org/index.php/topic,15488.msg225927.html#msg225927

Note that the referenced code makes dynamic API calls, but the behavior was the same even if the contents were changed to static API calls.

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

1. function AddClipboardFormatListener(Wnd: HWND): BOOL; stdcall; external 'user32.dll' name 'AddClipboardFormatListener';
2. function RemoveClipboardFormatListener(Wnd: HWND): BOOL; stdcall; external 'user32.dll' name 'RemoveClipboardFormatListener';
3.  

I tried copying this unit file to an empty project and writing a program with minimal code, and I verified that no errors occurred.

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ClipboardListener,
9.   StdCtrls, Clipbrd;
10.  
11. type
12.  
13.   { TForm1 }
14.  
15.   TForm1 = class(TForm)
16.     ListBox1: TListBox;
17.     procedure FormCreate(Sender: TObject);
18.     procedure FormDestroy(Sender: TObject);
19.   private
20.     CL: TClipboardListener;
21.     procedure ClipboardChanged(Sender: TObject);
22.   public
23.  
24.   end;
25.  
26. var
27.   Form1: TForm1;
28.  
29. implementation
30.  
31. {$R *.lfm}
32.  
33. { TForm1 }
34.  
35. procedure TForm1.FormCreate(Sender: TObject);
36. begin
37.   CL:=TClipboardListener.Create;
38.   CL.OnClipboardChange:=@ClipboardChanged;
39. end;
40.  
41. procedure TForm1.FormDestroy(Sender: TObject);
42. begin
43.   CL.Free;
44. end;
45.  
46. procedure TForm1.ClipboardChanged(Sender: TObject);
47. begin
48.   ListBox1.Items.Add(Clipboard.AsText);
49. end;
50.  
51. end.
52.  

Have tried to compile using external debug file? I asked this earlier and didn't see any response tobit
The exe file can get very large due to the attached debug file.

U could have some resource size issue and I see u are using a script manager

I'm not using an external debug file.
I'm also trying both the debug function of Lazarus when enabled and when not.

[CCRDude]

It takes some time, but there are two standard ways to go:

• Stepping through all code, including unit initializations, using F7
• "Disabling" (commenting out) all initialization code (not just in units, but also all FormCreate/FormShow/FormActivate/Create on the form) and step by step re-adding it

AddClipboardFormatListener is something typical to look for by security software, since any kind of simple password stealer might use that. Add a few other criteria (unsigned, recently changed due to recompile), and it might easily trigger some bad heuristics.

I would move AddClipboardFormatListener from FormCreate to the first call to FormActivate, because I like to have the window shown as fast as possible, and to avoid that your listbox additions happen during the creation stage.

[TakamiChie]

I asked you twice and please read this ..

 "Have you tried using an EXTERNAL debug file"?

 And you reply stating you are not using a EXERNAL debug file..

  The Key point in the question is to get you to use an EXTERNAL debug file to make the EXE file much shorter and from there please try to debug.

I'm sorry, I didn't understand the meaning of the sentence.
The problem this time is that RunError (204) occurs, and since I could not see the relationship between it and reducing the EXE size, I thought it was a translation mistake and interpreted it as a translation mistake.

Also, I don't understand what it means to use an external debug file. Is it to enable the "Use external debug symbol file" option?
And does it make the EXE size smaller than disabling the debugging feature itself?

If using an external debug file does not reduce the EXE size rather than disabling the debugging function, the fact that the application does not start even if the debugging function is run with the debugging function disabled will prove that reducing the EXE size did not solve the problem.

[TakamiChie]

Thanks for the reply.

I would move AddClipboardFormatListener from FormCreate to the first call to FormActivate, because I like to have the window shown as fast as possible, and to avoid that your listbox additions happen during the creation stage.

Got a very good tip. Thank you.

When the operation of the program was verified based on this hint, it was confirmed that the error occurred.


Because the PC was initialized due to another factor of machine trouble, the final factor has been unknown, but I would like to use it as a hint for future development.