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

[TakamiChie]

The app I'm developing in Lazarus is no longer working at all than yesterday(12/16).

When debugging on Lazarus, an error seems to have occurred in the CreateForm method of the lpr file.

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

1. begin
2.   RequireDerivedFormResource:=True;
3.   Application.Title:='ClipboardMonitor';
4.   Application.Scaled:=True;
5.   Application.Initialize;
6.   Application.CreateForm(TMainForm, MainForm); // <- Error occurs
7.   Application.Run;
8. end.
9.  

At the point where the error occurred in the above code, "Exception class 'RunError(204)'" was generated. It seems that the error occurs.

When following the process in the step-in, it was found that an error occurred in "TWinControl.WSRegisterClass" of "wincontrol.inc".
You know that an error has occurred before the form's method is called.

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

1. class procedure TWinControl.WSRegisterClass;
2. begin
3.   inherited WSRegisterClass; // <- Error occurs
4.   RegisterWinControl;
5.   RegisterPropertyToSkip(TWinControl, 'ParentDoubleBuffered', 'VCL compatibility property', '');
6.   RegisterPropertyToSkip(TWinControl, 'ImeMode', 'VCL compatibility property', '');
7.   RegisterPropertyToSkip(TWinControl, 'ImeName', 'VCL compatibility property', '');
8. end;
9.  

If you deploy and run the application in another environment that you own, it is working as expected.

* Windows PC(Windows 10 Home 21H1)
* Windows Sandbox Environment

From this, it is thought that the problem occurs not only by the problem in the program but also by some changes on the PC, but there is no change made to the PC the day before yesterday (12/15), and it is a state that does not know what to do at all.

Just in case, after checking the SMART of the disk, "DISM.exe /Online /Cleanup-image /Restorehealth" and "sfc /scannow" were executed to confirm that all problems were repaired.

If this happens, where is it correct to investigate?

[TakamiChie]

I forgot to write, but the environment I'm using is Windows 10 Professional 21H2 64bit, Core i5-7500 CPU @ 3.40GHz, 32.0 GB RAM.

[ccrause]

Is the problem specific to this project, or does it occur with a new project with only an empty form too?

[TakamiChie]

Thanks for the reply.

Is the problem specific to this project, or does it occur with a new project with only an empty form too?

Yes. This is a project-specific issue.
There were no problems with empty projects and forms with the same LCL components as this project.

The LCL components used in this form are as follows.

• TMemo
• TSplitter
• TStatusBar
• TIpHtmlPanel
• TPopupMenu
• TActionList

[dbannon]

Just to be clear here TakamiChie, are you saying that your code builds fine but crashes when you run it ?

But if you take the newly made binary to another system, it runs OK ?

When it crashes on you working machine, are you running it from within the IDE ? Or standalone ?

If it only crashes in the IDE, have you tried running it, still in the IDE but without debugging ?

Davo

[Zvoni]

And which FPC/Laz-Version do you use?

[TakamiChie]

Thanks for the reply.

Just to be clear here TakamiChie, are you saying that your code builds fine but crashes when you run it ?

Yes. The build succeeds, but crashes at run time.

But if you take the newly made binary to another system, it runs OK ?

Yes. If you move the created binaries to another environment, it will work fine.

When it crashes on you working machine, are you running it from within the IDE ? Or standalone ?

I did all of the following:

• Debugging execution on the IDE.
• Run the binary with debug information stand-alone.
• Run binaries standalone with no debug information left.

In all, the program was killed before the application's screen was fully displayed.

And which FPC/Laz-Version do you use?

Lazarus Version: 2.0.12
FPC Version: 3.2.0

[Zvoni]

Runerror 204

204 Invalid pointer operation
    You will get this in several cases:

        if you call Dispose or Freemem with an invalid pointer
        in case New or GetMem is called, and there is no more memory available. The behavior in this case depends on the setting of ReturnNilIfGrowHeapFails. If it is True, then Nil is returned. if False, then runerror 204 is raised.

Sounds like you're out of memory or your physical RAM is damaged

[Martin_fr]

Might need more details on the error.... But let's go there later.
Let's look at what we have.

You may want to start with "4a", and then check the other points.

When following the process in the step-in, it was found that an error occurred in "TWinControl.WSRegisterClass" of "wincontrol.inc".

1) Menu: Project > View Project Source
That should be the file from which you already quoted. With all the "Application.*" calls.

It should start with

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

1. program YourProgramsName;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   {$IFDEF UNIX}
7.   cthreads,
8.   {$ENDIF}
9.   TestDbgControlForm,
10.   Interfaces, .........
11.  

Make sure "Interfaces" is in the "uses" clause.

2)
- Open "Project Options"
- Page "Compiler Options" > "Config and Target"
On the bottom of the page it should say

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

1. Current LCL WidgetSet: "win32"

Make sure it is "win32", since you are on Windows. (Yes, this is correct for 64bit too)

3) Do you have any unit with an "initialization" unit?
If you do, does it call any LCL functions like "ShowMessage", or use a "TOpenDialog" ....

In order to find out, set a breakpoint on

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

1.   RequireDerivedFormResource:=True;

Or, on whatever is the very first line, in the "begin" block of the "project source".

If the error happens, before the breakpoint is reached, then you most likely have something in an "initialization" section.

4)
Do a clean build.

a) You can choose menu: Run > Build

b) Clean by hand
Open the folder with the project.
===> At this point: Backup the entire folder.

There is either a "lib" (or "units") dir.
It contains an x86_64-win64 or i386-win32 subdir.
-> From that subdir, remove all files.

Open all Forms in your project, and modify them (move them a few pixel on your monitor, so the coordinates are changed), the save them.
(The "forms" bit, is 99.9% NOT related to your issue, but just to be save.)

Now  "build" again, and test.

5)
More info, if nothing so far has helped or revealed at least more details.

Open the menu: View > Debug Windows > Stack
Copy the content when you hit the error.

The top, up to 3 entries may not have unit/lines. The may have names like "FPC_RUNERROR", "FPC_EXCEPTION", reference to system, sysutils.
After that, if the next lines in the stack, do not have unit names and lines, go to menu: Tools > "Configure build IDE", and add -gw  to the Custom options. No need to build, just save. Build and run again, hopefully the stack now has lines.

[dbannon]

yes, the fact that it runs OK on other machines says its probably not a code issue.

I'd be running a memcheck first off .....

(Most linux install ISOs offer to do a memcheck before booting, be a good start ..)

But Windows does have a limited number of a few particular resources too, not my field.

Davo

[marcov]

Security software is also always a possibility. Specially if you have something that initializes network on those forms.

[wp]

The usual suspect when something suddenly does not work any more, is the virus scanner which could have received an update with a "super-intelligent" feature a minute ago. Please read my notes on this in the other thread: https://forum.lazarus.freepascal.org/index.php/topic,57575.msg428315.html#msg428315

[marcov]

The usual suspect when something suddenly does not work any more, is the virus scanner which could have received an update with a "super-intelligent" feature a minute ago. Please read my notes on this in the other thread: https://forum.lazarus.freepascal.org/index.php/topic,57575.msg428315.html#msg428315

A firewall blocking e.g. the creation of a socket can also be the cause. Which is why I generalized to "security software"

[TakamiChie]

Thanks for the reply.

Sounds like you're out of memory or your physical RAM is damaged

yes, the fact that it runs OK on other machines says its probably not a code issue.

I'd be running a memcheck first off .....

(Most linux install ISOs offer to do a memcheck before booting, be a good start ..)

But Windows does have a limited number of a few particular resources too, not my field.

For RAM problems, I tried Running Windows Memory Diagnostics (MdSched.exe), but no particular problems were detected.

Security software is also always a possibility. Specially if you have something that initializes network on those forms.

I use windows security features.

Therefore, as an item to exclude from the scan of [Windows Security >Virus & threat protection > Virus & threat protection Settings > Excluded], I set two folders of the project folder and the folder with lazarus executable as excluded folders and executed again.

However, there was no change in the content of the error.

In addition, This application does not use the function to access the Internet.

1) Menu: Project > View Project Source
That should be the file from which you already quoted. With all the "Application.*" calls.

It was confirmed that it is a method call of the Application object except for the setting of the RequestDerivedFormResource variable described later.

Interfaces units are also included in the uses.

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

1. uses
2.   {$IFDEF UNIX}{$IFDEF UseCThreads}
3.   cthreads,
4.   {$ENDIF}{$ENDIF}
5.   Interfaces, // this includes the LCL widgetset
6.   Forms, Main, ClipboardListener, Utils, Settings, Localization, Preferences,
7.   ScriptManager, ScriptProcess, AboutDialog;
8.  

2)
- Open "Project Options"
- Page "Compiler Options" > "Config and Target"

Yes. It is set to win32.

3) Do you have any unit with an "initialization" unit?
If you do, does it call any LCL functions like "ShowMessage", or use a "TOpenDialog" ....

There are unit files listed in the "initialization" section, but only two are done:

* The process of loading a resource file in lrs format
* Windows API loading process

There is no action involving the display of dialogs.

4)
Do a clean build.

a) You can choose menu: Run > Build

b) Clean by hand

I tried both operations, but no change occurred (no error message has changed).

5)
More info, if nothing so far has helped or revealed at least more details.

Open the menu: View > Debug Windows > Stack
Copy the content when you hit the error.

When the IDE configuration has not been changed, it looks like this:

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

1. #0 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0
2. #1 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0
3. #2 ?? at :0
4. #3 SYSTEM_$$_SETMULTIBYTERTLFILESYSTEMCODEPAGE$WORD at :0
5. #4 ?? at :0
6. #5 fpc_widestr_setlength at :0
7. #6 ?? at :0
8. #7 ?? at :0
9. #8 ?? at :0
10. #9 fpc_unicodestr_to_widestr at :0
11. #10 ?? at :0
12. #11 ?? at :0
13.  

It was found that the execution of the program stopped in the following places only if no breakpoint was set after the configuration change of the build construction.

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. #5 ?? at :0
7.  

After this, when the execute button is pressed, the process proceeds, but the following message is displayed, and the application is terminated.

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

1. Project ClipboardMonitor raised an exception class 'External: ? exception.
2.  
3. applicable address 7FFDC3DA4F69
4.  

[Seenkao]

продублируйте проект. В дубликате: удалите файл *.lpi, удалите файл ресурсов. Откройте проект из Lazarus через файл *.lpr.

Возможно вам повезёт и ваш проект запустится. Не забудьте прописать необходимые пути заново.

То что я написал - это не лучшее решение, но бывает рабочим способом избежания проблем.

Google translate:
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.