See the link to “Installing SQL Server 2005 Breaks DHCP Server” for details on this problem. We encountered the same problem but many months after SQL Server was removed. It seems to be a problem with a wrong registry value for the VSS service.
As per Microsoft: "This behavior can occur if you include .mdb files in a virus scan. Because of the length of time the scan requires, WINS and DHCP do not correctly initialize in Windows". See ME245194
for mored details.
From a newsgroup post: "After a great deal of wasted time, this issue has been resolved. The problem was due to insufficient permissions on the clustered volume. The DHCP Server service requires that the SYSTEM account have full control permissions on the root of the volume on which the DHCP database is stored. These permissions must exist on the root, as in “P:\” for example. It is not sufficient that the permission exists only on the actual database directory. In the case of this particular problem, the database directory had been assigned the correct permissions but there were no SYSTEM account permissions on the root of the drive. Once the permissions were added to the root of the drive, the DHCP Server service started normally. Interestingly, the WINS service, which also relies on the Jet database engine, does not seem to require this permission setting as DHCP does".
See the link to "EventID 1004 from source DHCP" for more details on this event.
See "www.mcse.ms/message833741". It helped me to get rid of this error.
Usenet posts suggest reinstallation of the latest service packs and if possible, a restore of the DHCP configuration files.