CN109426591B - Method and equipment for guarding multiple processes of windows single program - Google Patents
Method and equipment for guarding multiple processes of windows single program Download PDFInfo
- Publication number
- CN109426591B CN109426591B CN201710787819.0A CN201710787819A CN109426591B CN 109426591 B CN109426591 B CN 109426591B CN 201710787819 A CN201710787819 A CN 201710787819A CN 109426591 B CN109426591 B CN 109426591B
- Authority
- CN
- China
- Prior art keywords
- daemon
- closed
- information
- processes
- starting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1438—Restarting or rejuvenating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention provides a method and equipment for guarding multiple processes of a windows single program, wherein the method comprises the following steps: receiving the name of a target windows program and executing the following steps at regular time: acquiring ID information of all started processes related to the target windows program; comparing the ID information of all started processes with the ID information of all the daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not; if a newly started process exists, adding the newly started process into a daemon list of the daemon process; and/or if the closed process exists, judging whether the closed process needs to be restarted, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameters. The invention realizes the protection of a plurality of processes of a single program.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a method and equipment for guarding multiple processes of a windows single program.
Background
Generally, a daemon is used for guarding a single process of a program, and the daemon is used for restarting the process when the guarded process is closed for some reason. However, in actual development, a certain program needs to be started by multiple processes, and multiple processes all need to be protected.
The protection of multiple processes started by a program involves more difficult problems, for example, the relevant starting parameters of the processes may be different, and even the directories started by the processes may be different, so that the protection of multiple processes started by a program is not easy to implement. Therefore, it is desirable to provide a method for implementing the protection of multiple processes started by a program.
Disclosure of Invention
In order to solve the problem that the prior art is not easy to realize the guard of a plurality of processes started by a certain program, the invention provides a method and equipment for guarding a plurality of processes of a windows single program.
According to one aspect of the present invention, there is provided a method of daemon a plurality of processes of a windows single program, comprising:
receiving the name of a target windows program and executing the following steps at regular time:
s1, acquiring ID information of all started processes related to the target windows program;
s2, comparing the ID information of all started processes with the ID information of all daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not;
s3, if a newly started process exists, adding the newly started process into a daemon list of the daemon process; and/or the presence of a gas in the gas,
s4, if the closed process exists, acquiring the starting parameter and the exit code of the closed process, and judging whether the closed process needs to be restarted according to whether the starting parameter is successfully acquired and the value of the exit code, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameter.
Wherein the method further comprises:
if the target windows program is obtained to have a new starting process, writing starting parameters and exit codes of the new starting process into a daemon configuration file under a directory where the target windows program is located;
and if the process is obtained to be actively closed by the user, updating the exit code of the process actively closed by the user in the daemon configuration file through the ID information of the process actively closed by the user.
Wherein the step S1 further includes:
s11, acquiring a snapshot handle of a process list in the system and traversing all system processes in the process list;
s12, comparing the process names of all the system processes obtained by traversing with the names of the target windows program, and acquiring the ID information of all the started processes related to the target windows program;
s13, closing the process list snapshot handle and releasing the system resource.
Wherein the step S11 further includes:
calling a CreateToolhelp32Snapshot function to obtain a Process list Snapshot handle in the system, pointing to the head of the Process list through a Process32First function, and traversing all system processes in the Process list through a Process32Next function.
Wherein the step S3 further includes:
s31, if a newly started process exists, acquiring the file name of the newly started process, which contains a starting path, according to the ID information of the newly started process;
s32, storing the ID information and the file name of the newly started process into the daemon list of the daemon process to update the daemon list.
Wherein the step S31 further includes:
and for all the newly started processes, acquiring handles of the newly started processes by using an OpenProcess function through the ID information of the newly started processes, and acquiring the file names of the newly started processes by using a GetModuleFileNameExA function.
The step of writing the starting parameters and the exit codes of the new starting process into the daemon configuration file under the directory where the target windows program is located further comprises the following steps:
calling a WriterivateProfileStrongA function to write the starting parameters and the exit codes of the new starting process into a daemon configuration file under a starting directory where the new starting process is located by taking the ID information of the new starting process as a key, wherein the default of the exit codes is set to be 1; correspondingly, the step of updating the exit code of the user actively closing the process in the daemon configuration file through the ID information of the user actively closing the process further comprises:
and calling a WriterivateProfileStrngA function to set the exit code of the process actively closed by the user in the daemon configuration file to be 0 by taking the ID information of the process actively closed by the user as a key.
Wherein the step S4 further includes:
s41, if a closed process exists, acquiring a starting path of the closed process according to the file name of the closed process stored in the daemon list;
s42, accessing the daemon configuration file under the starting path, and calling a GetPrivateProfileTringA function to acquire the starting parameters and the exit code of the closed process;
s43, if the starting parameter is successfully obtained and the exit code is 1, determining that the closed process is an abnormal closing process, calling a CreateProcesssA function to restart the abnormal closing process according to the starting parameter and the file name, obtaining ID information of a new process after the abnormal closing process is restarted, and updating the ID information of the abnormal closing process stored in a daemon list by using the ID information of the new process; alternatively, the first and second electrodes may be,
if the acquisition of the starting parameter fails or the exit code is 0, not restarting the closed process, and deleting the relevant information of the closed process in a daemon list of the daemon process.
According to another aspect of the present invention, there is provided an apparatus for daemon a plurality of processes of a windows single program, comprising: a memory, a processor, and a bus,
the processor and the memory complete mutual communication through the bus;
the memory stores program instructions executable by the processor, which invokes the program instructions in the memory to perform the method as previously described.
According to yet another aspect of the invention, there is provided a non-transitory computer readable storage medium storing computer instructions which cause the computer to perform the method as described above.
The method and the device for guarding the multiple processes of the single windows program have the advantages that all the processes of the started guarded program in the system are polled regularly through the daemon process to obtain all the newly started processes and the closed processes, the newly started processes are guarded, the abnormally closed processes are restarted, and the multiple processes of the single windows program are guarded.
Drawings
FIG. 1 is a flowchart illustrating a method for daemon multiple processes of a windows single program according to an embodiment of the present invention;
fig. 2 is a schematic flowchart based on step S1 in the foregoing embodiment according to another embodiment of the present invention;
fig. 3 is a schematic flowchart based on step S3 in the foregoing embodiment according to another embodiment of the present invention;
fig. 4 is a schematic flowchart based on step S4 in the foregoing embodiment according to another embodiment of the present invention;
fig. 5 is a schematic structural diagram of an apparatus for daemon multiple processes of a windows single program according to another embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.
As shown in fig. 1, a flowchart of a method for daemon multiple processes of a windows single program according to an embodiment of the present invention includes:
receiving the name of a target windows program and executing the following steps at regular time:
s1, acquiring ID information of all started processes related to the target windows program;
s2, comparing the ID information of all started processes with the ID information of all daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not;
s3, if a newly started process exists, adding the newly started process into a daemon list of the daemon process; and/or the presence of a gas in the gas,
s4, if the closed process exists, acquiring the starting parameter and the exit code of the closed process, and judging whether the closed process needs to be restarted according to whether the starting parameter is successfully acquired and the value of the exit code, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameter.
Specifically, a target windows program is a daemon program, and a daemon process guards the target windows program, and first needs to receive a name of the daemon program, and then regularly traverses all started processes related to the daemon program in a system. In S1, the daemon process first acquires all processes in the process list of the system, where all processes in the process list of the system are started at the current time, then screens out all started processes related to the daemon program from the system process list according to the name of the daemon program, and acquires ID information of all started processes related to the daemon program.
And S2, the daemon compares the acquired ID information of all started processes related to the daemon program with the ID information of all daemon processes stored in the daemon list of the daemon process, judges whether a newly started process and a closed process exist in the system, and further can acquire the ID information of the newly started process and/or the closed process. When the daemon process executes to step S2 for the first time, the daemon list of the daemon process is empty, and at this time, all the started processes related to the daemon program in the system are newly started processes. All processes which are started in the system in the last period and are related to the windows program to be protected are stored in the daemon list of the daemon process. Comparing the ID information of the started process with the ID information of all the daemon processes in the daemon list of the daemon process, namely comparing the acquired ID information of the started process with all the processes related to the daemon programs in the system after the previous period is finished, if new ID information occurs, it is indicated that a newly started process exists in the current system, and the new meaning is obtained by comparing the new ID information with the previous period. If some ID information is acquired, it indicates that the process in the current system has a process that has been closed in the previous period.
According to the result of step S2, steps S3 and/or S4 are performed accordingly, specifically including the following three cases:
if only a newly started process exists, the newly started process is added into a daemon list of the daemon process so that the daemon process can daemon the newly started process, and through the step, the daemon process of the embodiment of the invention can daemon a plurality of processes and simultaneously defend a plurality of processes started by a user at any time.
If only closed processes exist, firstly acquiring starting parameters and exit codes of the closed processes, wherein in the embodiment of the invention, each started process corresponds to the starting parameters and the exit codes, the starting parameters are used for restarting the process, the exit codes are used for indicating whether the process is actively closed or abnormally closed by a user, the daemon process is ignored for the process actively closed by the user, and the daemon process can be restarted according to the starting parameters for the abnormally closed process. Then, judging whether the closed process needs to be restarted or not according to the success of the acquisition of the starting parameter and the value of the exit code, and if the starting parameter can be successfully acquired and the exit code also indicates that the process is abnormally closed, indicating that the process needs to be restarted; and if the starting parameter cannot be successfully acquired or the exit code indicates that the process is actively closed by the user, ignoring the process and deleting the process from the daemon list of the daemon process. If the process needs to be restarted, restarting the closed process according to the acquired starting parameters; or if the restart is not needed, deleting the relevant information of the closed process from the daemon list of the daemon process.
If a newly started process and a closed process exist at the same time, adding the newly started process into a daemon list of the daemon process; meanwhile, judging whether the closed process needs to be restarted or not, if so, restarting the closed process, so that the daemon process can continuously daemon the closed process; and if the restart is not needed, the process is not restarted, and the related information of the closed process is deleted from the daemon list.
And the daemon process regularly and repeatedly executes the steps to realize the daemon on the target windows program.
According to the method for guarding the multiple processes of the single windows program, all the processes of the started guarded program in the system are regularly polled through the daemon process to obtain all the newly started processes and the closed processes, the newly started processes are guarded, the abnormally closed processes are restarted, and the multiple processes of the single windows program are guarded.
Based on the above embodiment, the method further comprises:
if the target windows program is obtained to have a new starting process, writing starting parameters and exit codes of the new starting process into a daemon configuration file under a directory where the target windows program is located;
and if the process is obtained to be actively closed by the user, updating the exit code of the process actively closed by the user in the daemon configuration file through the ID information of the process actively closed by the user.
Whether in the process interval that the daemon processes poll the processes related to the target windows program in the system for any two times or in the process that the daemon processes poll the processes related to the target windows program in the system for any one time, if the system acquires that the processes of the daemon programs are started successfully, the starting parameters and the exit codes of the newly started processes are written into the daemon configuration file under the directory where the daemon programs are located. It has been mentioned above that the start parameter is used to restart the process, typically information such as port number, server, etc., and the exit code is used to indicate whether the exit of the process is actively closed by the user or an exception occurs. For example, the exit code may be set to 1 by default, the exit code being 0 indicates that the user normally exits, and when normally exits, the daemon process does not need to restart the process; the exit code is other values to indicate that the process exits abnormally, and the abnormal exit indicates that the daemon process is required to restart the process.
When the daemon starts, the daemon configuration file is read. However, once the daemon process is started, if the system administrator changes the daemon configuration file, the daemon process needs to be notified to reread the daemon configuration file, and the daemon process can acquire the starting parameters and the exit codes corresponding to the process by rereading the daemon configuration file, so that restarting and other actions are performed. Note that, here, a plurality of processes are started in the program under one directory, and although information such as parameters is written in the same daemon configuration file, the information is marked by process ID numbers, and therefore, the information does not affect each other.
If the system acquires that the user actively closes the process and the daemon process does not need to daemon the process actively closed by the user, updating the exit code of the process actively closed by the user in the daemon configuration file through the ID information of the process actively closed by the user, for example, setting the exit code of the process actively closed by the user to be 0 to indicate that the process normally exits.
It can be seen that whether the daemon process needs to be restarted or not is determined by the user, and the possibility of starting the process which is not needed by the user is avoided. By writing the information of the daemon configuration file, the related parameter information of the program started process and the information of whether the daemon process is actively closed or not can be known.
As shown in fig. 2, a schematic flow chart based on step S1 in the foregoing embodiment is provided for another embodiment of the present invention, that is, step S1 further includes:
s11, acquiring a snapshot handle of a process list in the system and traversing all system processes in the process list;
s12, comparing the process names of all the system processes obtained by traversing with the names of the target windows program, and acquiring the ID information of all the started processes related to the target windows program;
s13, closing the process list snapshot handle and releasing the system resource.
Step S11 is specifically to call a CreateToolhelp32Snapshot function to obtain a Snapshot handle of a Process list in the system, point to the head of the Process list through a Process32First function, and traverse all system processes in the Process list through a Process32Next function.
Then, in S12, the process name of the system process obtained by traversal is compared with the name of the target windows program, so that the basic information of the relevant process started by the target windows program in the current system can be obtained, where we only need to obtain the process ID information.
Finally, executing S13, calling the CloseHandle function to close the process list Snapshot handle obtained by the CreateToolhelp32Snapshot function, so as to release the system resource.
As shown in fig. 3, a schematic flow chart based on step S3 in the foregoing embodiment is provided for another embodiment of the present invention, that is, step S3 further includes:
s31, if a newly started process exists, acquiring the file name of the newly started process, which contains a starting path, according to the ID information of the newly started process;
s32, storing the ID information and the file name of the newly started process into the daemon list of the daemon process to update the daemon list.
Specifically, in step S31, for all newly started processes, the handle of the newly started process is obtained by using the OpenProcess function through the ID information of the newly started process, and the filename of the newly started process is obtained by using the getmodulefilenemeexa function. The process filename contains the path the process started. Knowing the path for starting the process, the data of the daemon configuration file "daemon. data" of the process can be acquired through the path, and the step is to confirm the starting path of the process, so that the daemon configuration file corresponding to the process can be accurately accessed.
Then, step S32 is executed to save the ID information of the newly started process and the file name of the process in a daemon list. The process in the daemon list is the process which needs to be protected by the daemon process, when one process is closed due to an abnormal reason, the daemon process accesses the starting parameter in the daemon configuration file of the process through the file name of the process, and then restarts the daemon process according to the starting parameter. And finally calling a CloseHandle function to close the handle of the process opened by the OpenProcess function.
Based on the above embodiment, the step of writing the start parameter and the exit code of the new start process into the daemon configuration file in the directory where the target windows program is located further includes:
calling a WriterivateProfileStrongA function to write the starting parameters and the exit codes of the new starting process into a daemon configuration file under a starting directory where the new starting process is located by taking the ID information of the new starting process as a key, wherein the default of the exit codes is set to be 1; correspondingly, the step of updating the exit code of the user actively closing the process in the daemon configuration file through the ID information of the user actively closing the process further comprises:
and calling a WriterivateProfileStrongA function, and setting an exit code of the process actively closed by the user in the daemon configuration file to be 0 by taking the ID information of the process actively closed by the user as a key.
Specifically, the ID information of the newly started process is used as a key to distinguish each process conveniently, and then the start parameter and the exit code corresponding to the process can be conveniently searched in the daemon configuration file according to the ID information of each process. Although the starting parameters and the exit codes of the processes are written into the same daemon configuration file, the process ID information is used as a mark, and the process ID information cannot influence each other. Calling a WriterivateProfileStrongA function to write the starting parameters and the exit codes of the new starting process into a daemon configuration file 'daemon.data' under a starting directory where the new starting process is located by taking the ID information of the new starting process as a key, wherein the default of the exit codes is set to be 1;
correspondingly, the step of updating the exit code of the user actively closing the process in the daemon configuration file through the ID information of the user actively closing the process further comprises:
and calling a WriterivateProfileStrongA function, and setting an exit code of the process actively closed by the user in the daemon configuration file "daemon. And setting the exit code of the process which is actively closed by the user to be 0, wherein the process is normally exited.
As shown in fig. 4, a schematic flow chart based on step S4 in the foregoing embodiment is provided for another embodiment of the present invention, that is, step S4 further includes:
s41, if a closed process exists, acquiring a starting path of the closed process according to the file name of the closed process stored in the daemon list;
s42, accessing the daemon configuration file under the starting path, and calling a GetPrivateProfileTringA function to acquire the starting parameters and the exit code of the closed process;
s43, if the starting parameter is successfully obtained and the exit code is 1, determining that the closed process is an abnormal closing process, calling a CreateProcesssA function to restart the abnormal closing process according to the starting parameter and the file name, obtaining ID information of a new process after the abnormal closing process is restarted, and updating the ID information of the abnormal closing process stored in a daemon list by using the ID information of the new process; alternatively, the first and second electrodes may be,
if the acquisition of the starting parameter fails or the exit code is 0, not restarting the closed process, and deleting the relevant information of the closed process in a daemon list of the daemon process.
Specifically, step S4 is to process the closed process. For all closed processes, acquiring a directory started by a daemon process through the information of the process file name stored in a daemon list, and then accessing a daemon configuration file' daemon. If the relevant parameters of the process can be obtained and the exit code is not 0, determining that the closed process is an abnormal closed process and needs to be restarted, calling a CreateProcesssA function to restart the process through the starting parameters corresponding to the process and the process file name, obtaining the ID information of the started process, and updating the ID information of the closed process stored in the daemon list by using the new ID information of the process; if the starting parameter is not acquired or the exit code is 0, it indicates that there is an abnormal condition or the user actively closes the process, the process is not started, and the relevant information of the process stored in the daemon list is deleted in the daemon list, wherein the relevant information includes the ID information and the file name of the process.
Fig. 5 is a schematic structural diagram of an apparatus for daemon multiple processes of a single program according to another embodiment of the present invention, including: a memory 51, a processor 52, and a bus 53,
the processor 52 and the memory 51 complete mutual communication through the bus 53;
the memory 51 stores program instructions executable by the processor 52, and the processor 52 calls the program instructions in the memory to perform the method according to the embodiments, for example, including: s1, acquiring ID information of all started processes related to the target windows program; s2, comparing the ID information of all started processes with the ID information of all daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not; s3, if a newly started process exists, adding the newly started process into a daemon list of the daemon process; and/or S4, if a closed process exists, acquiring a starting parameter and an exit code of the closed process, judging whether the closed process needs to be restarted according to whether the starting parameter is acquired successfully and the exit code, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameter.
According to yet another aspect of the present invention, there is provided a non-transitory computer readable storage medium storing computer instructions that cause the computer to perform a method as described in the various embodiments above, for example, comprising: s1, acquiring ID information of all started processes related to the target windows program; s2, comparing the ID information of all started processes with the ID information of all daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not; s3, if a newly started process exists, adding the newly started process into a daemon list of the daemon process; and/or S4, if a closed process exists, acquiring a starting parameter and an exit code of the closed process, judging whether the closed process needs to be restarted according to whether the starting parameter is acquired successfully and the exit code, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameter.
Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: various media that can store program codes, such as ROM, RAM, magnetic or optical disks.
The above-described embodiments of the apparatus for providing multiple processes for daemon a windows single program are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, the method of the present invention is only a preferred embodiment and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (7)
1. A method for daemon a plurality of processes of a windows single program, comprising:
receiving the name of a target windows program and executing the following steps at regular time:
s1, acquiring ID information of all started processes related to the target windows program;
s2, comparing the ID information of all started processes with the ID information of all daemon processes in the daemon list of the daemon process, and judging whether a newly started process and a closed process exist or not;
s3, if a newly started process exists, adding the newly started process into a daemon list of the daemon process;
s4, if a closed process exists, acquiring a starting parameter and an exit code of the closed process, judging whether the closed process needs to be restarted or not according to whether the starting parameter is successfully acquired and the value of the exit code, and if the closed process needs to be restarted, restarting the closed process according to the acquired starting parameter;
wherein the method further comprises:
if the target windows program is obtained to have a new starting process, writing starting parameters and exit codes of the new starting process into a daemon configuration file under a directory where the target windows program is located;
if the process is obtained to be actively closed by the user, updating an exit code of the process actively closed by the user in the daemon configuration file through the ID information of the process actively closed by the user;
the step of writing the starting parameters and the exit codes of the new starting process into the daemon configuration file under the directory where the target windows program is located further comprises the following steps:
calling a WriterivateProfileStrongA function to write the starting parameters and the exit codes of the new starting process into a daemon configuration file under a starting directory where the new starting process is located by taking the ID information of the new starting process as a key, wherein the default of the exit codes is set to be 1;
correspondingly, the step of updating the exit code of the process actively closed by the user in the daemon configuration file by the ID information of the process actively closed by the user further comprises:
calling a WriterivateProfileStrngA function, taking the ID information of the process actively closed by the user as a key, and setting an exit code of the process actively closed by the user in the daemon configuration file to be 0;
wherein the step S4 further includes:
s41, if a closed process exists, acquiring a starting path of the closed process according to the file name of the closed process stored in the daemon list;
s42, accessing the daemon configuration file under the starting path, and calling a GetPrivateProfileTringA function to acquire the starting parameters and the exit code of the closed process;
s43, if the starting parameter is successfully obtained and the exit code is 1, determining that the closed process is an abnormal closing process, calling a CreateProcesssA function to restart the abnormal closing process according to the starting parameter and the file name, obtaining ID information of a new process after the abnormal closing process is restarted, and updating the ID information of the abnormal closing process stored in a daemon list by using the ID information of the new process; alternatively, the first and second electrodes may be,
if the acquisition of the starting parameter fails or the exit code is 0, not restarting the closed process, and deleting the relevant information of the closed process in a daemon list of the daemon process.
2. The method according to claim 1, wherein the step S1 further comprises:
s11, acquiring a snapshot handle of a process list in the system and traversing all system processes in the process list;
s12, comparing the process names of all the system processes obtained by traversing with the names of the target windows program, and acquiring the ID information of all the started processes related to the target windows program;
s13, closing the process list snapshot handle and releasing the system resource.
3. The method according to claim 2, wherein the step S11 further comprises:
calling a CreateToolhelp32Snapshot function to obtain a Process list Snapshot handle in the system, pointing to the head of the Process list through a Process32First function, and traversing all system processes in the Process list through a Process32Next function.
4. The method according to claim 1, wherein the step S3 further comprises:
s31, if a newly started process exists, acquiring the file name of the newly started process, which contains a starting path, according to the ID information of the newly started process;
s32, storing the ID information and the file name of the newly started process into the daemon list of the daemon process to update the daemon list.
5. The method according to claim 4, wherein the step S31 further comprises:
and for all the newly started processes, acquiring handles of the newly started processes by using an OpenProcess function through the ID information of the newly started processes, and acquiring the file names of the newly started processes by using a GetModuleFileNameExA function.
6. An apparatus for daemon a plurality of processes of a windows single program, comprising: a memory, a processor, and a bus,
the processor and the memory complete mutual communication through the bus;
the memory stores program instructions executable by the processor, which invokes the program instructions in the memory to perform the method of any of claims 1 to 5.
7. A non-transitory computer-readable storage medium storing computer instructions that cause a computer to perform the method of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710787819.0A CN109426591B (en) | 2017-09-04 | 2017-09-04 | Method and equipment for guarding multiple processes of windows single program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710787819.0A CN109426591B (en) | 2017-09-04 | 2017-09-04 | Method and equipment for guarding multiple processes of windows single program |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109426591A CN109426591A (en) | 2019-03-05 |
| CN109426591B true CN109426591B (en) | 2021-01-01 |
Family
ID=65513800
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710787819.0A Active CN109426591B (en) | 2017-09-04 | 2017-09-04 | Method and equipment for guarding multiple processes of windows single program |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109426591B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110704281A (en) * | 2019-10-14 | 2020-01-17 | 山东超越数控电子股份有限公司 | Method for monitoring system operation |
| CN112000382B (en) * | 2020-08-26 | 2023-10-13 | 绿盟科技集团股份有限公司 | Linux system starting method and device and readable storage medium |
| CN112052098A (en) * | 2020-09-02 | 2020-12-08 | 北京微步在线科技有限公司 | Process protection method and device |
| CN112860408A (en) * | 2021-03-03 | 2021-05-28 | 苏州沁游网络科技有限公司 | Process keep-alive method, device and system in cloud reality machine and storage medium |
| CN113946815B (en) * | 2021-10-21 | 2022-08-26 | 深圳致星科技有限公司 | Authorization method for federal learning and privacy computation |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101290587A (en) * | 2008-06-12 | 2008-10-22 | 中兴通讯股份有限公司 | Realization progress start-up and control process |
| CN101980171A (en) * | 2010-10-08 | 2011-02-23 | 广东威创视讯科技股份有限公司 | Failure self-recovery method for software system and software watchdog system used by same |
| CN104216795A (en) * | 2013-06-04 | 2014-12-17 | 上海联影医疗科技有限公司 | Multiprocess protection system and implementation method thereof |
| CN106371911A (en) * | 2016-09-06 | 2017-02-01 | 北京海誉动想科技股份有限公司 | Method for rebooting guarded process by daemon processes |
| CN106371927A (en) * | 2016-09-09 | 2017-02-01 | 深圳创维数字技术有限公司 | Linux daemon process realization method and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102469035B (en) * | 2010-11-05 | 2016-01-20 | 腾讯科技（深圳）有限公司 | The method and apparatus of striding course communication |
-
2017
- 2017-09-04 CN CN201710787819.0A patent/CN109426591B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101290587A (en) * | 2008-06-12 | 2008-10-22 | 中兴通讯股份有限公司 | Realization progress start-up and control process |
| CN101980171A (en) * | 2010-10-08 | 2011-02-23 | 广东威创视讯科技股份有限公司 | Failure self-recovery method for software system and software watchdog system used by same |
| CN104216795A (en) * | 2013-06-04 | 2014-12-17 | 上海联影医疗科技有限公司 | Multiprocess protection system and implementation method thereof |
| CN106371911A (en) * | 2016-09-06 | 2017-02-01 | 北京海誉动想科技股份有限公司 | Method for rebooting guarded process by daemon processes |
| CN106371927A (en) * | 2016-09-09 | 2017-02-01 | 深圳创维数字技术有限公司 | Linux daemon process realization method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109426591A (en) | 2019-03-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109426591B (en) | Method and equipment for guarding multiple processes of windows single program | |
| CN111258850B (en) | Method and device for updating software information based on Linux system | |
| CN103019687A (en) | Method and device for displaying pop window information | |
| EP3015987A1 (en) | System update method, apparatus, and device | |
| CN106775981B (en) | Process processing method and device and computer readable medium | |
| CN110619226A (en) | Platform-based data processing method, system, equipment and storage medium | |
| CN109783316B (en) | Method and device for identifying tampering behavior of system security log, storage medium and computer equipment | |
| CN112650658A (en) | Application program exception recording and reproduction method, device and storage medium | |
| WO2015106710A1 (en) | Contact information processing method, apparatus, and system | |
| JP2017520820A (en) | Behavior information identification method corresponding to danger file and behavior information identification device corresponding to danger file | |
| CN103019906A (en) | Method, device and system for popup information display | |
| CN110727585A (en) | Memory leak detection method and device, electronic equipment and readable storage medium | |
| CN110837377A (en) | Application program updating method and device, storage medium and electronic equipment | |
| CN111241198B (en) | Data synchronization method and device and data processing equipment | |
| CN106446681B (en) | Checking and killing virus method and apparatus | |
| CN108446144B (en) | Application program starting method and device, terminal and storage medium | |
| CN110221952B (en) | Service data processing method and device and service data processing system | |
| CN109445951B (en) | Information processing method and device | |
| JP2010231568A (en) | Event determination device, event determination program, and event determination method | |
| US9727378B2 (en) | Persistent unenrollment for devices under management | |
| CN115080355B (en) | Method and device for generating monitoring log | |
| CN115688187B (en) | Method, device and equipment for safety management of hard link data and storage medium | |
| CN110866253B (en) | Threat analysis method and device, electronic equipment and storage medium | |
| CN117473501A (en) | Hidden process detection method, device, equipment and medium based on eBPF | |
| CN111158746B (en) | Method and device for acquiring call relationship |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |