Ora-07445 error record caused by one windows Vulnerability

Some time ago, some customers failed to respond to their oracle Database listening. The system error log sent was:

Error application TNSLSNR. EXE, version 0.0.0.0, error module orahasgen10.dll, version 10.2.0.1, error address 0x00000000000000d0.

The customer is working on the Two-host MSC servers, but after the host fails to listen, it will not automatically switch to the slave machine. After the customer turns off the master server, all resources are switched to the slave server. Then, the database runs on the slave server and the master server is waiting for repair.

So I remotely went to the client and asked the client to restart the host. After modifying the host configuration information, I started the listener directly. As a result, I asked the client host to run (not to mount the database, but to run the instance and listen ). After that, I checked the oracle listening log and Database Log and found no valuable error information. Only the following information is found in the oracle warning log:

ORA-07445: Exception error: core dump [ACCESS_VIOLATION] [unable_to_trans_pc] [PC: 0x78EE1CD6] [ADDR: 0x15A0] [UNABLE_TO_READ] []

I query the region.

I first suspected the oracle bug, so I contacted the application provider to confirm whether the oracle version they used was 10.2.0.1, because my colleague told me that the oracle 10g version 10.2.0.4 is relatively stable. The answer I get is that the database versions used by the customers of their applications are 10.2.0.1.

After reading the logs for half a day, you still cannot determine where the problem is.

Later, I went to the customer's site and found that the master server monitoring was still running. However, when I refresh the service and find that the listener is in the stopped status, I manually start the listener without any error. However, if I refresh the service immediately, the listener is again in the stopped status. It seems that there is indeed a problem with the listener.

First, I suspected that there was a problem with the orahasgen10.dll module. So I downloaded this module from the Internet. At that time, I didn't know where to put it, so I directly put it in the c: \ windows \ system32 \ directory, and use regsvr32/s "c: \ windows \ system32 \ orahasgen10.dll" for registration.

After that, I will delete the current listener and restart to re-establish the listener service. Then, the cluster resources are switched to the master server so that the master server can be mounted to the database for operation. This operation lasted for about 18 hours, and the master server listened down again. The same error was reported:

Error application TNSLSNR. EXE, version 0.0.0.0, error module orahasgen10.dll, version 10.2.0.1, error address 0x00000000000000d0.

The time when the problem occurred was I observed at the site. Before I found the TNSLSNR. EXE error in this package, I first encountered the following error:

Error application svchost.exe, version 5.2.20.0.1830, error module netapi32.dll, version 5.2.20.0.1830, error address 0x000521a2.

So I checked the system log of the last service downtime and found that this error was also reported before the error of the packet TNSLSNR. EXE. Later, I checked the "Instance name core" under the database cdump directory. log File. This file records the memory information when an error occurs. It is found that the orahasgen10.dll module exists in the "$ ORACLE_HOME \ BIN \" directory. Originally, the operations on the dll module were useless.

I checked the error message about netapi32.dll on the Internet. Microsoft vulnerabilities discovered. For details, refer:

Http://social.microsoft.com/Forums/zh-CN/540fdce5-abac-4c80-85f7-5a258dd314fa/-svchostexe-5237901830-netapi32dll-5237901830-0x000521a2? Forum = windowsserversystemzhchs

Http://support.microsoft.com/kb/958644/zh-cn

The solution is to patch KB958644.

Http://www.microsoft.com/zh-cn/download/details.aspx? Id = 7605

After completing the patch, migrate the database back to the master server for operation. After observing the patch, no errors have been found in the past week or so.

Review the entire process. It should be because of the windows overflow vulnerability caused by netapi32.dll, which makes the network function unavailable. Network exceptions cause the listening to report errors, resulting in database downtime, and reported an error in the ora-07445.