To run a program prompt for access violation at address workaround

Now the solution is published:
Right-click My Computer. Click Properties.
In System Properties, click Advanced.
In performance, click Settings.
In Performance options, click Data Execution Protection.
Click Add. Select the program you want to run.
Ok. It's so simple.

Workarounds for access violation (illegal access) errors

Access violation (illegal access), General Protection Fault (Generic protection Error) or invalid page Fault (Invalid page fault), although not the same, but essentially always caused by the same error. Access violation is often encountered when a program run by a computer user tries to access a store that is not specified for use.
Access violation at address < hexadecimal values >
In module < application name >
Read of address < hexadecimal values >
Windows users may often see an error message similar to this: "Error:access violation at address 836556f8 (004096DA). Read of Address 836556f8 (00401000) ". As a Delphi program developer, there is more chance of encountering this error than other users (^_^).
Once Windows writes data outside its allocated store, it overwrites commands or data from other programs or even operating systems. Once this happens, the operating system will be paralyzed or shut down in some way, and you must restart the computer. For example, when the next program in Windows nt/2000 encounters this error, Dr. Watson appears and stops the program, captures some quick details, and then records them in textual form. Access violation is one of some of the most annoying Windows programs that you encounter. The purpose of this article is to let you find out the solution of Access violation in Delphi. First of all, access violation does not have any relationship with Microsoft Access.

When we develop the program with Delphi, we can divide the access violation we encounter into two main classes: the runtime and the design period.

First, the design period of access violation

1. Hardware reasons
Access violation is prone to design periods when you start or close the Delphi IDE and compile a Delphi project. Access violation information may be caused by a variety of reasons, including the system BIOS, operating system, or hardware drivers, and some sound cards, video cards, and network cards can actually cause this error in your computer's operation. Why do you say that? Every card in the computer has its device driver. For different manufacturers, different versions of Windows, or different versions of Delphi, you may experience different problems. The following steps may help you solve these problems:

1. Follow the necessary steps to verify that there is no conflict between the drivers that you installed.

2. Sometimes lowering the display resolution may stabilize some wacky graphics drivers.

3. If you are using a dual-processor motherboard, make sure that the steps for each processor are modified.

4. Note the use of the latest drivers for all hardware on the computer.

2. Software reasons
Although Windows is the most popular operating system in Intel's computers, the misuse of the application can cause the operating system to crash quickly due to the inherent fragility and bugs of Windows systems (sometimes the operating system itself can be inexplicably paralyzed). Choosing a more stable program development environment is the solution, and here are a few steps to help you prevent some access violation from happening:

(1) Despite the popularity of Windows 9X, Windows nt/2000 has proven to be a much more stable environment in many ways, almost for all Windows code platforms.

(2) Ensure that the latest service pack is installed for Windows nt/2000. Each time you install the new version of the service pack, you will find that the machine becomes stable.

(3) for the various versions of Delphi you use on the current update or patch (BDE, ADO ... ), which is a good way to prevent mistakes in advance. Try to use the latest Delphi patch--access violation the number of errors especially in the design period will be greatly reduced.

(4) If you are often randomly encountering access violation errors in the IDE, it is likely that you have installed a bad control, package, or a wizard that is not written or compiled by the version of Delphi that you are using. Try to uninstall the custom control (or package) one at a later until the problem is resolved, and then contact the control vendor to follow the result of the problem.

(5) Check the computer for any useless things and program conflicts. Strange software programs and beta products often cause access to violation errors.

(6) If there are errors in the system Setup, Access violation errors may also occur frequently. If you keep encountering an error message like access violation, record these details and then notify the software manufacturer that may be causing the error.
These are all my suggestions for the design-time access violation error.

Second, the operating period of access violation
What are the common run-time access violation errors for Delphi? How to prevent?

Any software development will encounter a situation where you write the program and test it and send it everywhere, and the user tells you that it failed.

You might consider compiling your program with the compile instruction {$D}--delphi to create an image file that helps locate the source code for an access violation error. Project Options dialog box (project| options| Linker & Compiler) lets you specify everything you need. For the unit file, the debug information and the unit's object code are recorded in the unit file. When compiling a program that uses this unit, the debug information increases the size of the unit file and adds additional memory overhead, but it does not affect the size and speed of the final executable file. Contains debug information and image files (project| options| Linker) option does not complete the line information until the {$D +} compilation directive.

Access violation usually manifests itself only in one aspect of the program. When the problem first occurs, it is important to consider what the user is doing, and then find a breakthrough here. From the user's point of view, your program stops their work, and they tell you that the problem appears to have you postpone solving the problem. However, communicating with users is the only effective way to identify problems and improve procedures.

Now you will know how to easily find the exact path, the source code file, and the line where the access violation error occurred, in cases where only the conflicting address is given to you:
"Search-find Error ...".

When a run-time access violation appears, your users get an error message similar to the following:
Access violation at address < hexadecimal values >
In module < application name >
Read of address < hexadecimal values >

If your program contains debug information compilation in the Delphi IDE, you can navigate to the line that caused the error source code.
One of the most common causes of Access violation errors in Delphi programs is the use of an object that has not been created. If the second address < hexadecimal value > is FFFFFFF or 0000000, is the likelihood that you visit? An object that has not been built. For example, you invoke an event for a form, but the form is not created automatically, and there is no code instantiation.

? Procedure Tfrmain.oncreate (Sender:tobject);
var badform:tbadform;
Begin
This will generate access violation
Badform.refresh;
End

Suppose Badform is in the list of "Available Forms" windows of the Project option-this window needs to be created and released manually. Calling the Refresh method of the Badform window in the code above will cause access violation.

If you make "Stop on Delphi Exceptions" active in the Debugger Options window, the following message pops up:
The message states the eaccessviolation has occurred. The eaccessviolation is the exception class for invalid memory access errors.

This is the information you will see when you design the program, the next message box will appear, and then the program fails:
Access violation at address 0043f193
In module ' Project1.exe '
Read of Address 000000.

The first hexadecimal number 0043f193 is the address of the run-time error of the compiled code (Project1.exe) that occurs with access violation. Select the menu item "search|" in the IDE. Find error ... ", click the" OK "button after entering the address (0043f193) in the dialog box. Delphi will recompile your project file and then display the line of code where the run-time error occurred, which is the Badform.refresh line.

The following is a list of the most common causes of access violation errors in the Delphi environment. This list is not and is not likely to overwrite all possible access violation scenarios. Please send your access violation information on the forum, and you can try to solve the problem together-real real-world cases are generally more obscure than listed errors.

1. Calling an object that does not exist
As mentioned above, most access violation are justified by using objects that have not been created or have been disposed of. To prevent this type of access violation from happening, make sure that any objects you access are created first. For example, when a table is positioned in a data module that is not created (removed from the Auto-crete window), you may open the table in the OnCreate event of the form.

In the following code, an access violation appears after invoking an object (B:tbitmap) event that has been deleted:
var B:tbitmap;
Begin
B:=tbitmap.create;
Try
Take some action on the B object
Finally
B.free;
End
...
Because B has been released, an access violation error will appear
B.canvas.textout (0,0, ' This is an Access violation ');
End

2. Non-existent API parameters
If you try to pass a non-existent parameter to the WIN API function, an access violation error will appear. The best way to resolve this type of access violation error is to consult the win API help to see the parameter information and parameter types of this API function call. For example, it is always guaranteed not to pass an invalid pointer to a buffer parameter.

3. Let Delphi release
When an object has another object, let it do the removal work for you. Because by default, all forms (automatically created) belong to the Application object. When an application finishes, it frees the Application object and releases all the forms. For example, if you automatically create two forms (Form1/unit1 and Form2/unit2) at the beginning of a program, the following code causes access to violation errors:
Unit Unit1;
...
Uses unit2;
...
Procedure Tform1.call_form2
Begin
Form2.showmodal;
Form2.free;
Access violation error will appear
Form2.showmodal;
End

4. Kill the exception
Never break the temporary exception object (E), and handling an exception automatically frees the exception object. If you manually release the exception object yourself, the program tries to release it again, and then an access violation error occurs:
zero:=0;
Try
Dummy:= 10/zero;
Except
On E:ezerodivide do
Messagedlg (' Can't divide by 0! ', mterror, [Mbok], 0);
E.free.////access violation error will appear
End

5. Retrieving an empty string
An empty string is without any data. That is, retrieving an empty string is equivalent to accessing an object that does not exist, which causes access to violation errors:
var s:string;
Begin
S:= ";
S[1]:= ' a ';
Access violation error will appear
End

6. Direct reference pointer
You must refer to the pointer indirectly, otherwise you will change the pointer address and may break other storage units:
Procedure Tform1.button1click (Sender:tobject);
Var
P1:pointer;
P2:pointer;
Begin
Getmem (P1, 128);
Getmem (p2, 128);
The next line causes access violation error
Move (P1, p2, 128);
The next line method is correct
Move (p1^, p2^, 128);
Freemem (P1, 128);
Freemem (p2, 128);
End
These are all my suggestions for the run-time access violation error, and I hope you can also make some comments about the access violation errors that appear in your program.