Paragon hard disk manager "scripts" process question?

I have Paragon Hard Disk Manager 2009. When it runs a scheduled backup operation, a process runs on the computer called "script" or "scripts" and can be viewed under the task manager.

I just wanted to know what is normally the "set priority" of this process thread. Right now on my system it has "Realtime" priority. Is it supposed to run with this priority or has mine been changed somehow?

Thanks....

 

I don't think realtime is necessary. Normal or Above Normal suffice.

 

Well, thanks for responding.

I seem to remember it was set to either 'above normal" or "high" before, but now whenever the process runs, it runs with "realtime" priority. It causes problems like skipping, if I am watching a movie or a video clip simultaneously. I only started experiencing this problem 7-10 days ago.

Can you inform me how to manually set the priority of this process, so it runs with that priority from then onwards, as I was unable to find such an option.

All I can do now is to manually change the priority when the process is running, but when it runs again, it again defaults to "realtime".

Thanks.

 

I don't know of any way to permanently set the priority for a specific application. Windows should default all applications as normal unless specify through registry, shortcut with the priority parameters, or specific command line.

 

If you are using XP/Server 2003/Vista, you might have a look at Prio - not sure if it works on 7 yet.

Prio - Process Priority Saver. Free for personal use.

This compact program allows you to save the priority you specify for any process.

http://www.prnwatch.com/prio.html

Hope it helps

 

Okay, here is what I did. I uninstalled Paragon hard disk manger, rebooted, reinstalled Paragon and rebooted. Created a backup schedule and ran the script. The "scripts.exe" again defaulted to "realtime" priority!

It starts with normal priority but by the time the backup window shows 1% progress, if you again look at the priority of the scripts.exe it is on "realtime"

I thought uninstalling and reinstalling will correct the problem.

I will now use the software mentioned by SIW2 and see if I can set it to a lower priority. For this I need to know what the default priority for this process is. Can someone have a look in their Task manager during a backup process and let me know under what priority does this scripts.exe run on their systems? I will be grateful.

(Keep in mind, let the backup progress to at least 1% before you have a look at the scripts.exe thread priority)

awaiting a response..................




p.s. I am running Vista sp2 32-bit and I am using "Paragon hot processing" as the default hot processing engine.

 

Normal is the default.

 

Well, I used the software "Prio" mentioned by SIW2 and set the priority of scripts.exe to normal. Unfortunately it did not work. When the process started again on its scheduled time, it again started running with realtime priority.

It must be some registry value that might have got changed to cause scripts.exe to run with realtime priority.

Does anyone know how to correct it?

 

I seemed to have corrected the problem using the following steps below:

-Since the last uninstall did not work so this time I used Revo uninstaller to uninstall Paragon HDM. Then I rebooted. Unfortunately, even after this I still had to manually delete the "Paragon software" folder from inside my program files. I also had to delete the scheduled task scripts from inside my windows and system32 folders manually. I then searched inside my registry for the keyword "Paragon" and was alarmed to find more than a dozen entries still there. I deleted most but some just would not allow me to delete them. I gave up and ran a registry cleaner. I do not know if the paragon entries were actually deleted or not. It is rather alarming that even after uninstalling using a third party uninstaller, Paragon leaves so much junk behind!

-I reinstalled Paragon HDM and setup a backup schedule with my usual settings and ran the backup. It again defaulted to "realtime". I would have pulled out my mustache at this point, but luckily I do not wear one.

-It then occurred to me, since complete uninstall did not work, to change the hot processing engin. So, I setup another backup script but this time I chose VSS instead of the "paragon hot processing". Ran the schedule and voila! the scripts.exe was running with normal priority.

-I still do not know what caused the priority to shift from normal to realtime in the first place, as I have always used "paragon hot processing" and everything ran fine till about 2 weeks ago. I can also assume that even after doing a complete uninstall, Paragon HDM still left something behind, which prevented the scripts.exe to return to normal priority using the "paragon hot processing". All I can say is that I can no longer use "paragon hot processing". Perhaps a complete system format will solve the problem.

-In the end my problem is solved. Very bad of Paragon to leave stuff behind on the machine after uninstall.

Thank you for reading this and trying to help me solve my problem.

 

An addendum to the above post.

I installed Paragon HDM inside a VM running winXP. I ran the backup with "paragon hot processing" and the scripts.exe defaulted to Realtime priority.

Then I ran a backup with VSS and scripts.exe ran with normal default priority.

So, I can safely say that the problem is with using "paragon hot processing" for locking the volume. I probably did not realize it as I have a core 2 due processor and it masked the fact that scripts.exe was running with Realtime priority.

I will now permanently use VSS for doing live backups....

 

We generally suggest our users to use VSS unless there's a conflict. VSS does a better job of synchronizing multiple partitions, whereas Paragon Hot Progressing takes a snapshot of each partition at a time.

 

The backups and restores with "paragon hot processing" had always worked fine for me. I only do a backup of my OS partition only.

Can you point this out to the Paragon development team that using "paragon hot processing" causes the scripts.exe to run in Realtime priority. I am sure it is a software bug and not by design.

Incidentally, I only chose "paragon hot processing" over VSS, as it used to give me backups quicker than VSS. As it was working in Realtime and VSS was working with a Normal priority, it was to be expected. So, I became prejudiced against VSS for the wrong reasons.

 

Hi Raza0007,

Thanks for keeping us posted about this. I will do my best to forward this to the right people and hopefully we'll see the appropriate changes in future builds. Nonetheless, I hope either PHP or VSS is doing the job for you well.

 

Interestingly, I ran a long backup with PHP instead of VSS and scripts.exe was set to normal priority. I wonder if something was modified on your computer to set a permanent change in priority.

 

Maybe. I usually keep on trying different software and keep on tinkering with my system. So, it might be just my system. I have been using PHP for backups daily for the last 6 months and I only started noticing performance issues only 2-3 weeks ago.

By the way, I am using HDM 2009 pro. maybe the bug is version specific. so make sure you run PHP from HDM 2009 pro.

Anyway, my backups are running fine with VSS. So, I am happy...

 

Another update....

I just downloaded the Paragon Backup & Recovery 10 Free Edition and installed it inside Vmware running a fresh copy of Winxp sp3 32-bit.

I scheduled a backup with "best compression" and "paragon hot processing" and scripts.exe ran with "Real time" priority.

I then ran the backup with "best compression" and "VSS" and scripts.exe ran with "Normal" priority.

Now, unless all these different versions of Paragon have a special vendetta against me, I am assuming this will hold true for everybody. There appears to be a bug in the software when used with "paragon hot processing".

 

Paragon Tommy,

I recently ran into problems doing restores using backups created by VSS and I would like to shift back to PHP. Is there some hidden setting or some registry value that I can change that will cause a scheduled backup job using PHP to run in normal priority?

I have had it confirmed by three different users on three different machines, when a scheduled job is run using PHP it runs in real time priority mode only.

Can you ask the development team to provide some solution to this PHP issue, as I would like to use it instead of VSS, as it had been giving me reliable backups and restores for the last 8 months.

Thanks...

 

Hi Raza007,

I'll go ahead and forward this to the developer. For the meantime, I did however find an external solution.

There's a freeware program call Prio that can save the priority of the application.

http://www.prnwatch.com/download.html

Simply install Prio 32 or 64bit, restart. Manually execute a schedule back, while the backup is running, open Task Manager, change "scripts.exe" priority to normal.

Prio will retain the setting.

 

Thank you, I have already tried Prio as per advice of SIW2 (see post 5 in the thread), but it did not work in this particular case. I saved the priority of the scripts.exe when it was running, but during the next scheduled run it again defaulted to real time.

 

I think we're getting mixed results here. What I did to reproduced and retained the setting was setup a scheduled backup (not a "Back up now"). Then go to "Scheduled Task" tab, right-click the task and "Run Now". While the Backup is running, I opened Task Manager, right-click "Scripts.exe" and changed priority to Normal with "Save Prioirty" checked.

From there on, every scheduled backup I ran was in normal.

 

Okay, I just installed Prio, rebooted computer, went into Paragon and scheduled a backup job with PHP. Then in "scheduled tasks", I right-clicked on the task and hit "Run Now". Waited for the "Overall progress window" to reach "Data Writing" stage. I opened task manager and changed the priority of the scripts.exe from real time to normal. Save priority option was checked.

I then let the job to run for a few minutes and when the Over All progress window was showing 5% job done, I canceled the backup operation.

I again went to the same scheduled task inside Paragon and again hit "Run Now", waited for the progress window to reach "Data writing" stage. I again opened task manager and scripts.exe was running in Real time!


I guess, the only difference is that you do not let the "overall progress window" to reach the "data writing" stage. As when scripts.exe shows up in the task manager, it shows up with normal priority, but by the time 'data writing' is displayed in the "progress window", it has switched to real time mode.

Prio does not seem to help.

Please, check and make sure this is what is happening at your end too.

Thanks.

 

During "data writing", the scripts.exe priority is still in Normal on my side.

 

I have just tried it multiple times, with multiple runs, even unchecking and rechecking the 'save priority" option related to Prio. But on my system, when a scheduled task is run using PHP, regardless of what priority I set to the scripts.exe, it defaults to "Real Time" on the next run.

I am running 32-bit Vista. I will now test it inside Vmware running 32-bit winXP and see if it makes any difference.

 

I just installed Prio inside Vmware workstation running 32-bit winxp and repeated the above procedure. Even with Prio "save priority" checked, with PHP the scripts.exe always runs with "real time" priority.

So it is nothing to do either with my system or my OS.

Are you sure, you selected PHP when you scheduled a job at your end?

As a couple of days ago (post#14) in the thread, you were even unable to see scripts.exe running in Real time mode.....

Apparently, if paragon is not made aware of this bug they are going to roll it out in their future releases too. As I mentioned post#16 it is even present in Paragon Backup and Recovery 10 free edition, which was released only a month ago.

 

Raza0007,

Regardless if the workaround works or not, we have forwarded this to our support team in Moscow and developers to take another look. At the moment, I don't have an expected time of response or when it will be fixed in future builds. I will keep you posted and this thread open as much as I can.

I'm curious as to what other users have experienced. We're testing this as well on a few other of our machines.

Thank you.