Event ID: 474 Source: ESE

Event ID/Source search

Keyword search

Example: Windows cannot unload your registry file

EvLog 3.0 – Monitor an unlimited number of servers with $49/year

With the current low prices for servers and the need for processing power, even a small company may end up with quite a few of them. If ten years ago it was still common to see an entire company using just one server, these days that's no longer the case.
New computers are added to the network with the understanding that they will be taken care of by the admins. Keeping an eye on these servers is a tedious, time-consuming process. Even with 5 minutes per server (to check the logs and other parameters), it may take an hour to make sure that everything is ok and no "red lights" are blinking on any of the servers.

Event ID: 474 Source: ESE

Source: ESE

Type: Error

Description:
Information Store (<PID>) The database page read from the file "<path to edb file>" at offset <offset> for <value> bytes failed verification due to a page checksum mismatch. The expected checksum was <checksum> and the actual checksum was <checksum>. The read operation will fail with error <error code> (<error code>). If this condition persists then please restore the database from a previous backup.

English: Request a translation of the event description in plain English.

Comments:
EventID.Net
ME271987 suggest that this kind of error indicates a physical corruption in the information store.

See ME151789 for a description of Jet -1018 error.

ME314917 provides information on understanding and analyzing -1018, -1019, and -1022 Exchange database errors.
Click if the comment is good!

^{x
46}

Anonymous
In my case, this error occurred because .NET Framework 2.0 was corrupt. Reinstalling it solved the problem.
Click if the comment is good!

^{x
42}

J.M.Sanchez
Microsoft is a bit too quick to blame this error on hardware failure. We've extensively checked out the Exchange servers that were throwing these errors after the Exchange 2003 SP2 update. A full bit level check of all systems found no problems but Exchange would consistently throw out database corruption errors on deleted messages especially just prior to a backup. It turned out the "zero deleted messages" process was to blame. It was causing erroneous CRC values to be recorded. When we turned off this feature, all problems ceased. If you are afflicted with this problem in Exchange 2003, one easy way to solve the problem is for you to create a new message store and move your mailboxes to it. You can do so even with the system on-line, saving much grief.
Click if the comment is good!

^{x
38}

EventID.Net
- Error: -1018 = JET_errReadVerifyFailure - See ME810411.
- Error: -1018 - As per Microsoft: "In earlier versions of Exchange, event ID 475 is also used to report the occurrence of a -1018 error. Exchange 2003 SP1 does not use event ID 475. Exchange 2003 SP1 uses event ID 474 to report the occurrence of an unrecoverable -1018 error, and event ID 399 to report the occurrence of a recoverable -1018 error". See ME867626 for more details.

See MSEX2K3DB and the link to "Error code 1018" for additional information.
Click if the comment is good!

^{x
34}

Woodrow Wayne Collins
See ME812531.
Click if the comment is good!

^{x
33}

Jared Tucker
Error -1018 is a JET database (ESE) error. There are a few possibilities associated with this error:
1. You have anti-virus software running on the server and it is corrupting the information store
2. A hard disk is beginning to fail.
Click if the comment is good!

^{x
38}

Anonymous
There is no official support document availible from Microsoft which addresses this issue but you can infer a resolution. Because of the mismatched checksum the Exchange database cannot be treated as consistent. Sadly this means that no backups of the Exchange store which has this mismatch can be trusted. Reverting back to a backup of the store when there was no mismatch is the only safe option. Mail recieved since the mismatch may be lost. Backups of the content of individual mailbox can be trusted so after restoring the store to a consistent state is would be fine to restore the content of all the individual mailboxs to the latest backup.
One could also use Eseutil and Isinteg but "when you run repair there is always a chance of catastrophic data loss, and you should always have a backup of a database file before you attempt repair." See ME262196.
Click if the comment is good!

^{x
34}

Joseph Mikitish
In my case, this problem was fixed with eseutil /p. This may not be the best option in every situation. It is a good idea to run diagnostics on the hardware before trying to repair the Exchange database since this issue could indeed be hardware related, per ME327337.
Click if the comment is good!

^{x
34}

Private comment: Subscribers only. See example of private comment

Links: EventID 474 from source ESE98

Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...

Feedback: Send comments or solutions - Notify me when updated

Printer friendly