I couldn’t find this listed anywhere else, hence why I’ve joined and posted it. This is doubly annoying as when fullscreen game (Morrowind) crashed, the debug tool started to run. While off-screen the D+ window appeared and with the way Morrowind crashed I had to hard-shutdown my computer as I could not bring up the D+ window to allow dumprep to run.
The bug/issue
What you did: Ended a program that had crashed
What actually happened or you actually saw: Defense+ Alert about the “Windows Error Reporting Dump Reporting Tool”
What you expected to happen or see: Nothing (Have set always allow multiple times now)
How you tried to fix it & what happened: Have set the always trust this file or package
Files appended
Screenshots illustrating the bug: Attached
Screenshots of related event logs or the active processes list: No
A CIS config. report or file: No
Crash or freeze dump file: No
Your set-up
CIS version, AV database version & configuration used: Not sure, latest version with latest database version
Whether you imported a configuration, if so from what version: No
Defense+ and Sandbox OR Firewall security level: Safe Mode
OS version, service pack, bits, UAC setting, & account type: Windows XP, SP3, 32 bit, N/A, Admin account.
Other security and utility software running: None?
Could you check the file signature on Dumprep.exe please. You can use Run ~ Sigverif.exe. And check the resulting list of files without signature for Dumprep.exe.
Thanks - its the System32 version that is live. Just to confirm this conclusion you might want to try adding a trusted vendor to Trusted Vendors in the Computer Security Policy using this file. It should object and say that MS is already a trusted vendor if CIS thinks it is signed.
You are right about one thing, Comodo did object to it being added. However it objected because “The file does not seem to be a valid signed executable”.
dumprep uses only a small amount of the CPU when it runs, and it runs for only a few seconds before closing again.
Comodo has also complained about Windows Messenger. Basically the same bug, just a different file. It also says that its not a valid signed file…
I’m sure there are others but I can’t remember them right now. I have used the “Send this file to Comodo for analysis” option on dumprep.exe and msmsgs.exe so that might help.
Other information that might help:
To get the dumprep.exe message, I use Media Player Classic and cause it to crash by opening video files one after another until it crashes. the msmsgs.exe pops up when opening Outlook Express.
Error reporting is disabled. With “But notify me when critical errors occur” ticked.
cmdagent.exe is not running. I use Comodo to terminate this process as it regularly disrupts software from running. One application in particular stops responding for a few minutes while cmdagent.exe sits there using 99% of the CPU and up to 100mb of RAM.
The paging file is located on an external 1.5TB Harddrive, set to system managed size. All other drives (3) have it set to “no paging file”.
Not all Windows files are signed. In Windows XP more than in Windows 7. On my XP SP3 with all updates msmsgs.exe and dumprep are not signed. No Comodo bug here.
There is a backlog of submitted files that are waiting to be processed. Nothing we can do but wait and see.
[at]Eric
Hmm maybe, but don’t think so, but I don’t think this is a bug either. Are you judging by the file properties tab? In Windows confusingly, files which are catalogue signed do not have a certificates tab. Quite idiotic
On my XP SP3 machine dumprep is signed, presumably on Itchy’s as well as sigverif did not pick it up (though this tool can be confusing).
I think the reason may lie in the fact that Itchy has cmdagent disbled?
[at]Itchy
If you disable cmdagent CIS does not work - you do not have security coverage.
This should not be possible: “I use Comodo to terminate this process as it regularly disrupts software from running”. But it is. So this is in fact an issue, I think.
Your CPU issue is probably caused by files being sandboxed, or needing exclusion from BO protection. I’ll wait for your and Eric’s response but probably transfer this back to help tomorrow, so someone can help sort your CPU issue out.
You are welcome to post “I can terminate cmdagent using the APL” as an separate issue if you wish
Working on my Win 7 here and used Sysinternals Sigcheck on dumprep of XP and it says it is not signed. See attached image. For unknown reason sigcheck does not check msmsgs.exe.
The issue was caused because cmdagent.exe was not running. However in previous versions of Comodo (v3, v4) the issue never occurred, even if cmdagent.exe wasn’t running.
I doubt being able to terminate cmdagent.exe is a bug. I found that it can only be terminted via Comodo and not via other methods.
I still think this may be a bug due to the fact that this issue never existed in previous versions.
Also dumprep is signed according to sigcheck.exe
Turns out I need to use “” around the path for msmsgs.exe.
Further finding is that you can only do sigcheck on files of the active OS. In short when I booted my Windows XP SP3 installation both dumprep.exe and msmsgs.exe turned out to be signed. When I use sigcheck in Win 7 it cannot verify files from my XP installation.
