Subject: Unable to verify mssearch, sqlmangr, sqlservr.exe
Posted: 16 June 2013 at 12:25am
 I like you mentioning to install the entire Sysinternals Suite[...] |
I'm glad you found my advice helpful. The SysInternals tools are indispensable; they always have been.
| [...] does not run on older system. I’ll do a look-up for the latest version that will run on my older system and download it. |
Hopefully you found some success here, but I am skeptical about what you will be able to turn up for a few different reasons.
- The API calls used by SigCheck were not implemented in Windows 2000 Adv. Svr.
- I seem to recall a legitimate MS upgrade, like a service pack, that invalidated all of the OS files' digital signatures. This might be an issue for your scenario too; in which case, digital signatures would be broken and that would be the expected scenario. Your only option here would be to verify matching hashes between your binaries and known-good versions of the same binary.
- As another forum member indicated, Windows 2000 Advanced Server has reached/passed it's end-of-life date and is not officially supported by Microsoft anymore and there is good reason for that. I understand that you may have some reason or requirement that is forcing you into your situation. I feel for you. Your task is not impossible, but you have your cut out for you.
Honestly, I would take a step back and re-consider exactly what your problem is, any constraints you have, and what your goal(s) or desired outcome is. Just take a few minutes to mentally walk through it before you re-commit yourself to the path you have been following.
In your last post you mentioned
| [...] after a severe crash that has left the databases unable to connect |
- Do you fear/suspect that malicious code precipitated the crash? Hopefully not; which means, that hardware failure, power failure, unintentional software failure, or maybe human error. No matter how you slice it, you are left with some corruption that is resulting in the "[database's failure] to connect".
- Have you captured a ProcMon trace that covers the scenario? You may have to manually start your SQL server so that you can get ProcMon running before the failure happens. Otherwise, you will need to enable BootLogging and live with the disadvantage of not being able to collect network events when using the BootLogging feature.
- Do you have backups of your data? If you do then maybe it would be easier to stand-up a new server instance and restore the data from backup files. Even better, maybe your database files are not compromised and the problem connecting is related to the binaries. That might mean that you wouldn't need backups to successfully restore your database into a freshly installed server.
- What is the paranoia vs. cost-conscious demeanor on your team? Consider the man-hours that you are facing to fix and then maintain the issue before you. It would probably be more cost effective to pay for server resources from (pick your favorite F100 technology company). The catch is that you/your team have to reconcile the fact that your data is somewhat less under your control.
- ...
That should get your juices flowing. You might still decide that your original path is the correct one, but a quick sanity check is... well, sane.
If you do decide to continue down your original path and still want help I can offer a few more approaches. The simplest being something like "use FC.exe to compare two binaries" and up to the more complicated/involved Windows Debugging Tools (postmortem debugging from crash dumps, possibly live debugging (local/ring-3), or kernel debugging (requires multiple systems).