cvtres.exe

As I’ve not received any replies to a message about this I attached to an existing thread:

I am having serious problems with cvtres.exe, and apparently I don’ know how to keep Comodo Firewalll from causing this. I did read the existing threads on the subject, but don’t understand what other users did in Comodo to fix the problem. I have to suspect Comodo, as I never had this problem until a Comodo update a few days ago.

Vista Home Premium, SP1; Comodo 3.0.25.378.

I am getting two instances of the .exe running, causing the CPU to go to one hundred percent use. As far as I know, I don’t have any programs that use cvtres.exe, which seem to launch on their own. I was recording a VHS to the computer to convert to DVD; before I left for a run, CPU use was around 40%; when I returned, it was at 100%.

When the two instances of cvtres.exe appear in the Task Manager, I simply end both processes, which has no effect on any running programs as far as I can determine, it simply reduces the load on the CPU.

I would greatly appreciate detailed instructions on how to get Comodo to ignore cvtres.exe, as what I have done apparently has not had any effect. (Again, I don’t understand what others wrote about how they accomplished this, and I did not find anything in the Comodo help file that corresponded to the language used in the forum threads on the situation.)

Do you have Visual Studio? Any installation problems recently?

edit: Referenced post: Re: cvtres.exe (netframework) 99%

Take cvtres.exe for a spin at Jotti (just in case). What directory is it in? Do you have more than one copy?

Thanks for the quick reply.

  1. After I posted, I realized that I’d forgotten to state that, as far as I know, I have no programs that use cvtres.exe; that, of course, means that, no, I don’t have Visual Studio.

  2. No installation problems at all. Updates to Comodo and Avast, Windows Vista Updates, those are all that I recall over the past few weeks. Oh, yes, a move from Minefield (beta-test for Firefox 3) to FF3 RC1 and RC2, but no problems whatsoever with those two updates. I don’t know for certain when I first installed RC1, I can only state that I don’t believe the cvtres.exe problems started after that.

Thanks for the quick reply.

  1. Just tried to access Joti, no response. A boot scan by Avast a day or so ago found no problems.

  2. I forgot to mention, in my original post, that I have a mere three copies of cvtres.exe, for reasons quite unknown to me. One is in Windows\Microsoft.NET\etc. The other two are in two folders in Windows\winsxs; those two are, as I recall the only things in those folders.

[tried jotti again, got a “unable to connect to database, sysop has been notified” reply; shall try again later.]

I’m tempted to rename the latter two examples; I might even rename the first one, given that I can find no programs that actually use this .exe.

Of course, I have checked the computer’s moon-phase setting, which is correct, so that’s not the cause of the problem(s)…

I’ve had something like this myself previously, mine was caused by an nightmare .NET install by Ghost. I went back to a restore point, but I also knew where it started. Do you have anything regarding this issue in the Windows Event logs?

The only ways, that I can currently think of, that CFP might become an issue in relation to .NET, was if it is related to your .NET installation (which was causing wider problems) or if something, .NET related, was generating a lot of work for CFP (blocking, traffic/protocol/packet analysis, etc…).

Jotti: Try http://www.virustotal.com/

edit: Sorry, I should have said that these on-line scans (Jotti & VirusTotal) run the sample against many different AV engines (you’ll see) and some do generate false-positives.

I see nothing in the Event logs about Net nor about cvtres.exe.

I did not install NetFramework, it is part of Vista. As far as Comodo being the proximate cause of the problem, I was lead to that by a Google search, which turned up a few Comodo threads, such as https://forums.comodo.com/bug_reports/cvtresexe_netframework_99-t23317.0.html;msg164340 . However, I did not–as I wrote earlier–understand what the CFP users did in CFP to ameliorate the difficulty.

(I ought to have started off by thanking you; assistance is always appreciated. Intermittent problems, such as the current one, however, are never welcome, sigh.)

You could use something like Process Explorer to discover the parent process & the command line used to run the cvtres.exe processes. Also it might be worth using something like Autoruns to do a quick check on what is running at start-up (primarily the Logon tab in Autoruns).

If you keep trying to be helpful, you are likely to get a bad reputation…

Amicus certus in re incerta cernitur - A true friend is discerned during an uncertain matter

I’ve bookmarked both programs, shall download/install/run them, thanks.

When the computer had not gone to sleep after more than its normal two hours, I was certain I knew what the problem was.

I opened the Task Manager, and found (of course) that two copies of cvtres.exe were running.

I then looked at Process Explorer, which indicated that:

  1. Csrss.exe was involved. I determined that is “Client Server Runtime Process”, which seems to run without cvtres.exe. (In fact, there are two copies running after the recovery from blue-screen, discussed below.)

  2. Csc.exe, the Visual C# Command Interpreter involved; that file is in Net/Framework.

  3. There appeared to be a WordPerfect involvement, but my fiddling caused the computer to blue-screen before I could positively identify what part of WP might be a suspect.

  4. There may well have been some entries in Process Explorer beneath the WP entry, but the blue-screen also kept me from seeing any such.

I have not the foggiest idea what any of the above actually means; I can only report that which I saw in Process Explorer. I know that I’ve made no changes to my WP setup for a long time before the cvtres.exe problem(s) began, so even if it was shown in Process Explorer, I’d doubt that WP itself is a cause–but, of course, I also have no way of knowing if my supposition is correct.

Maybe Kail should go back to being grumpy. :wink:

I’m not grumpy… and my reputation is as low as it’s ever been (ie. intact). ;D

Blue screen? Do you mean a BSOD?

!ot!

Yes, BSOD–and I’m rather certain that it was my fault, as I suspect that, in trying to restore the CPU to a reasonable level of use, I killed a process that Windows Vista requires.

And now for the news at 1219 Local: I was on-line for a while early this morning, then ate breakfast, etc. When I returned to the computer, it was asleep. As soon as I awakened the machine, SuperAntiSpyware started its scheduled weekly scan.

When I left for a run, the CPU was around 40%. Upon returning to the computer, Super reported no problems found, but Process Explorer again showed the CPU at 100%.

After closing Super, only Firefox and Thunderbird were open (along, with, of course, Comodo, and other such programs.)

Looking at Process Explorer, I found two instances of cvtres.exe active; both were the file in Net/Framework. When I killed those, the CPU dropped momentarily, then went back to 100%; that’s the first time that has happened.

I also found csc.exe was running, plus two instances of calcs.exe. The latter two were the basic culprits, each using forty percent or more of the CPU. A quick Google search said that calcs.exe is critical, so instead of trying to kill their processes (and likely getting another BSOD), I rebooted.

Right now, CPU is at 5%, with no instances of csc.exe, cvtres.exe, nor cacls.exe running. I’m way beyond understanding any of this, what is causing it, how to fix it (along with everything else in the world…).

Hi Someone Else,

Are you using Comodo Memory Firewall (CMF)? If so, you can try to add cvtres.exe to CMF exclusion list.
If you are not using CMF, issue is probably due to SafeSurf toolbar installed. Not sure about exclusion list implemented along with SafeSurf (as i don’t have it installed), but try to find it: if successful add cvtres.exe there.

And finally, if nothing will help, you can do the following to resolve issue until it fixed in upcoming versions:

  • either revert to 3.0.22 or earlier version of CF;
  • or rename/delete guard32.dll under x:\windows\system32 (and reboot);
  • or uninstall SafeSurf (if this is possible).

Well, you are certainly weird, for you have answered my original question! What a strange thing to do…

Thanks, I greatly appreciate your assistance: Yes, I am using Comodo Memory Firewall. I had no idea what was meant in the earlier threads about cvtres.exe and “CMF”; thus, I did not know what to do–and that is why I had asked for detailed instructions on how to handle the cvtres.exe problem. Having now been told what CMF stands for, I have added cvtres.exe to the CMF exclusion list, and hope that that will fix the problem.

I’m not using the SafeSurf toolbar.

Valui ad satanam in computatrum meum invocandum - I succeeded in summoning Satan into my computer. Let us–or at least me–hope that your advice will exorcise him.

Sorry, i’m so used to these abbreviations like CF, CMF, that i forget people not familiar with them don’t understand what i’m talking about.

Yep, let’s hope :a0

I thought I was going to be able to report that adding cvtres.exe to CMF had fixed the problem. Unfortunately, last night a new culprit was found: When the computer again failed to go into sleep mode, I took a look at Process Explorer.

In PE, I found that two instances of java.exe were taking up most of the CPU, leaving the CPU stuck at 100% use. I killed both processes, which allowed CPU use to revert to a more reasonable few percentage point.

Any ideas on the latest difficulty?

Is it related to Comodo Firewall or Comodo Memory Firewall? I. e. when their drivers, libraries and services are disabled, does the problem remain? Simple script can help to temporarly disable CF, CMF instead of uninstalling them, however there are a couple of ways to do this manually.
Here is one variant:

to temporarly disable CF, add .tpm (just example) at the end of filename (e. g. app.exe.tpm instead of app.exe) for the following files:

  • guard32.dll under x:\windows\system32;
  • inspect.sys, cmdhlp.sys, cmdguard.sys under x:\windows\system32\drivers;
  • cmdagent.exe, cfp.exe under x:\program files\comodo\firewall;

to temporarly disable CMF do the same for the following files:

  • cmfd.sys under x:\windows\system32\drivers x:\program files\comodo\memory firewall;
  • cmf.exe under x:\program files\comodo\memory firewall;

where x - your system drive (where windows installed);

Once you renamed items you wanted, reboot computer.
These manipulations should help to identify whether CF or CMF or both are causing problems.

When you want revert back to “working” state, just delete .tpm at the end of filename for above mentioned files and reboot computer.

I think I need to create a script that places “As always, I appreciate your assistance” automatically in each of my replies in this thread, as that would save me all the effort of typing that in myself…

As to which program, Firewall or Memory Firewall, caused yesterday’s java.exe problem (assuming, obviously, that the problem was caused by one of those two), I have no way of knowing. Nonetheless, as my cpu problems only started after last week’s Comodo Firewall update, it seems relatively safe to conclude that they are caused by firewall or memory firewall.

I hate intermittent difficulties, as they are so hard to remedy. Your advice about adding cvtres.exe to Memory Firewall’s exclusions really seemed to fix that one; the java.exe problem is a new one.

So, thanks for the reference to which files can be renamed for testing purposes. I had concluded, even before my earlier posting this morning, that I needed to so something, but did not know what. I’m going to disable Memory Firewall later today (I’m recording yet another VHS tape for conversion to DVD now, so cannot reboot the computer.)

I guess that, after disabling CFM, I’ll just have to wait a few days to see if any further problems arise; if not, I’ll reenable it–and if something untoward occurs then, it would be relatively reasonable to conclude that whatever is causing the problem lies in CFM.