A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Mysterious behaviour of RUN box



 
 
Thread Tools Display Modes
  #1  
Old May 22nd 16, 07:34 PM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?

--
Terry, East Grinstead, UK
Ads
  #2  
Old May 23rd 16, 06:48 AM posted to microsoft.public.windowsxp.general
Micky
external usenet poster
 
Posts: 380
Default Mysterious behaviour of RUN box

[Default] On Sun, 22 May 2016 19:34:18 +0100, in
microsoft.public.windowsxp.general Terry Pinnell
wrote:

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?


You find the most interesing problems. Is it because you're from
East Grinstead?
  #3  
Old May 23rd 16, 08:09 AM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

Micky wrote:

[Default] On Sun, 22 May 2016 19:34:18 +0100, in
microsoft.public.windowsxp.general Terry Pinnell
wrote:

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?


You find the most interesing problems. Is it because you're from
East Grinstead?


Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.

--
Terry, East Grinstead, UK
  #4  
Old May 23rd 16, 09:52 AM posted to microsoft.public.windowsxp.general
David B[_3_]
external usenet poster
 
Posts: 187
Default Mysterious behaviour of RUN box

On 23-May-16 8:09 AM, Terry Pinnell wrote:
Micky wrote:

[Default] On Sun, 22 May 2016 19:34:18 +0100, in
microsoft.public.windowsxp.general Terry Pinnell
wrote:

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?


You find the most interesing problems. Is it because you're from
East Grinstead?


Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.


A slight aside, Terry - what 'facility' did you use to make your
recording? (It was crystal clear btw! :-) )

--
David B.
  #5  
Old May 23rd 16, 11:21 AM posted to microsoft.public.windowsxp.general
Paul
external usenet poster
 
Posts: 18,275
Default Mysterious behaviour of RUN box

Terry Pinnell wrote:
Micky wrote:

[Default] On Sun, 22 May 2016 19:34:18 +0100, in
microsoft.public.windowsxp.general Terry Pinnell
wrote:

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?

You find the most interesing problems. Is it because you're from
East Grinstead?


Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.


I'm at a loss as to how to debug that. As I don't know if there
is any entry in ProcMon that corresponds to a text entry widget.

Instead, I'd do an inventory of "interesting" programs. Perhaps
something like Keepass for passwords is used to automatically
enter passwords ? Or a copy of AutoIT ? There must be some
unique software on the machine. And, something with side effects.

If this started recently, you'd have to recollect when certain
things were added, to figure out a correlation.

I tried doing a search, but the results are so random as to be
hopeless. The trick is finding search terms that actually work.

While it would be easy to just wave my hands and say "keylogger",
somehow I doubt they'd be that clumsy.

Paul
  #6  
Old May 23rd 16, 06:32 PM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

David B wrote:

On 23-May-16 8:09 AM, Terry Pinnell wrote:
Micky wrote:



You find the most interesing problems. Is it because you're from
East Grinstead?


Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.


A slight aside, Terry - what 'facility' did you use to make your
recording? (It was crystal clear btw! :-) )


CamStudio 2.0. Very old (like a lot of my stuff) but a more recent
version still seems to be available, e.g:
https://sourceforge.net/projects/camstudio/

--
Terry, East Grinstead, UK
  #7  
Old May 23rd 16, 06:42 PM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

Paul wrote:

Terry Pinnell wrote:
Micky wrote:

[Default] On Sun, 22 May 2016 19:34:18 +0100, in
microsoft.public.windowsxp.general Terry Pinnell
wrote:

This started several days ago and has continued after a reboot. Typing
or pasting characters into the Run box takes about one second per
character. Making it now virtually unusable. My most frequent use is
for navigating quickly to often-used folders. A path like

C:\Documents and Settings\All Users\Application Data\MAGIX\Movie Edit
Pro 2014 Premium\VideoEffects\Collage\

currently takes getting on for two minutes before it's ready to open!

(Note: I typically use a macro 'shortkey' to paste folder frequently
used text strings. That example above is activated by typing '=co'.)

Keystrokes are working OK in all other applications I've tried.

Anyone have any idea of possible cause and fix please?
You find the most interesing problems. Is it because you're from
East Grinstead?


Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.


I'm at a loss as to how to debug that. As I don't know if there
is any entry in ProcMon that corresponds to a text entry widget.

Instead, I'd do an inventory of "interesting" programs. Perhaps
something like Keepass for passwords is used to automatically
enter passwords ? Or a copy of AutoIT ? There must be some
unique software on the machine. And, something with side effects.

If this started recently, you'd have to recollect when certain
things were added, to figure out a correlation.

I tried doing a search, but the results are so random as to be
hopeless. The trick is finding search terms that actually work.

While it would be easy to just wave my hands and say "keylogger",
somehow I doubt they'd be that clumsy.

Paul


Thanks Paul, appreciate your trying. I don't know if this will survive
long term but the following procedure has worked on half a dozen
occasions in the last hour or so: after opening the Run box, I
immediately close it again with Esc and then re-open it and proceed
with my entry, which displays at the proper fast speed.

Coming back to your point about conflicts, my initial step when this
first occurred was to close my macro program, Macro Express Pro, but
that didn't help. It's the darned inconsistency that's exasperating.

--
Terry, East Grinstead, UK
  #8  
Old May 23rd 16, 08:17 PM posted to microsoft.public.windowsxp.general
Paul
external usenet poster
 
Posts: 18,275
Default Mysterious behaviour of RUN box

Terry Pinnell wrote:
David B wrote:

On 23-May-16 8:09 AM, Terry Pinnell wrote:
Micky wrote:


You find the most interesing problems. Is it because you're from
East Grinstead?
Possibly - but moving house seems an extreme solution ;-)

I was about to add the good news that in the first few checks this
morning the problem had not occurred - only for it to reappear on the
next, and the next. Whether typing manually or pasting (with Ctrl+V or
right-click context menu).

Naturally, I'm looking for a conflict with another program or some
other pattern, but so far in vain. Frustrating.

I may next try running SysInternals ProcMon before the next test. But
that always delivers such a large list of entries that I can rarely
find useful clues. Anyone know what might be a suitable filter to
focus on Run box stuff?

Just tried again and this time I recorded it.
1. Opened the Run Box and started video recording
2. Used Backspace to delete the previous entry; interestingly that was
implemented immediately. On occasions, if used when typing a string,
that too has suffered the glacial effect.
3. Typed the string 'Typing quickly'.
4. Each character took about a second to get displayed, as you see.
https://dl.dropboxusercontent.com/u/...BoxGlacial.mp4

Yet next few tests were OK. Go figure.

A slight aside, Terry - what 'facility' did you use to make your
recording? (It was crystal clear btw! :-) )


CamStudio 2.0. Very old (like a lot of my stuff) but a more recent
version still seems to be available, e.g:
https://sourceforge.net/projects/camstudio/


Camstudio. Danger. Adware.

Use the Wikipedia entries for these software
items, to spot problems with Adware.

https://en.wikipedia.org/wiki/Camstudio

"This edit from Nick Smith, the "caretaker" of
CamStudio, "to finance future development,
CamStudio has chosen to use an ad-supported
installer"

It's true, that an older version was
adware-free. I might have had that one
here.

You might also notice that CamStudio cannot
generate an AVI over 4GB in size. It doesn't
appear to have an AVI 2.0 OpenDML implementation.
And even though two people from Google worked
on the software, it doesn't appear they knew or
cared about this most outrageous limitation.
Instead, one of the individuals played around
with multi-monitor capture.

As for the Open Source nature of the project,
I downloaded the source. Spent a week in Visual
Studio trying to set up a project file (did I
mention I hate Visual Studio for this?), only
to notice one of the source files is missing.
Talk about a ****er.

*******

Today, I use FFMPEG and the GDIgrab built-in filter.

# Grab a static build from here. I unpacked mine
# into C:\FFMPEG\bin and so on.

https://ffmpeg.zeranoe.com/builds/

# Command to get the precise name of the sound device

ffmpeg -list_devices true -f dshow -i dummy

# Using GDIgrab to capture video... One-liner command.

ffmpeg -framerate 60 -f gdigrab -i desktop
-f dshow -sample_rate 44100 -i audio="SoundMAX HD Audio"
-vcodec mjpeg -acodec pcm_s16le out.avi

On Win8 or Win10, try a framerate of 30, as
that could be the cap on gdigrab in those OSes.

The FFMPEG sample rate jitter is relatively high.
If you set framerate capture at 480FPS under
the right conditions, it turns into a train wreck :-)

On Linux, there is a bit more of a skew between
video and audio. The Windows is a bit more behaved
in that regard. In some cases, even a static offset
doesn't guarantee to correct it. It can be damn
hard to realign if there is "delay variation"
during the capture.

On Windows 7, disabling Aero can make capture
more efficient. Try changing themes for example.
This should help with both CamStudio and FFMPEG.

To capture Youtube video, disable hardware
acceleration in Flash. This puts the movie
video rendering in a render plane that GDIgrab
can "see". Dunno whether any tricks are needed
for HTML5 video standards.

You can record video with FRAPS on Windows 7,
and from any of three render planes. This makes
FRAPS one of the most capable capture tools. However,
Microsoft saw to it that the FRAPS method would
not work on Win8 or Win10, and the FRAPS site
may not list those OSes as supported. Because
basically, Microsoft defeated them. When I attempted
to test FRAPS years ago, it tried to inject its
DLL into every program files folder. The idea is,
it tries to capture by intercepting calls to the OS.

And now you might guess, when I needed to buy
an OS for the Test Machine, it was Windows 7.
With best (remaining) support for screen capture
technologies. Even if the support isn't all that
wonderful, it's better than later OSes. I can buy
a copy of FRAPS if I want. I can capture at
higher than 30FPS. If I needed to make a movie of
some Windows worked examples, I'd start with
Win7 as the platform.

Paul
  #9  
Old May 23rd 16, 08:20 PM posted to microsoft.public.windowsxp.general
Paul
external usenet poster
 
Posts: 18,275
Default Mysterious behaviour of RUN box

Terry Pinnell wrote:


Thanks Paul, appreciate your trying. I don't know if this will survive
long term but the following procedure has worked on half a dozen
occasions in the last hour or so: after opening the Run box, I
immediately close it again with Esc and then re-open it and proceed
with my entry, which displays at the proper fast speed.

Coming back to your point about conflicts, my initial step when this
first occurred was to close my macro program, Macro Express Pro, but
that didn't help. It's the darned inconsistency that's exasperating.


Does Macro Express Pro use a filter driver ?

And it could be that Macro Express Pro and some
other tool, are fighting over the same info flow.

Paul
  #10  
Old May 23rd 16, 10:47 PM posted to microsoft.public.windowsxp.general
David B[_3_]
external usenet poster
 
Posts: 187
Default Mysterious behaviour of RUN box

On 23-May-16 6:32 PM, Terry Pinnell wrote:
David B wrote:

[....]
A slight aside, Terry - what 'facility' did you use to make your
recording? (It was crystal clear btw! :-) )


CamStudio 2.0. Very old (like a lot of my stuff) but a more recent
version still seems to be available, e.g:
https://sourceforge.net/projects/camstudio/


Many thanks, Terry.

I've noted Paul's comments too!
--
David B.
  #11  
Old May 24th 16, 08:33 AM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

Paul wrote:

Terry Pinnell wrote:


Thanks Paul, appreciate your trying. I don't know if this will survive
long term but the following procedure has worked on half a dozen
occasions in the last hour or so: after opening the Run box, I
immediately close it again with Esc and then re-open it and proceed
with my entry, which displays at the proper fast speed.

Coming back to your point about conflicts, my initial step when this
first occurred was to close my macro program, Macro Express Pro, but
that didn't help. It's the darned inconsistency that's exasperating.


Does Macro Express Pro use a filter driver ?


Sorry, not sure I'd recognise one of those if it jumped out and bit
me! (Even after googling it.)

And it could be that Macro Express Pro and some
other tool, are fighting over the same info flow.


But presumably not after Macro Express Pro is terminated?

--------------------

Fingers crossed, three tests so far this morning and all OK. The
problem started suddenly for an unknown reason; maybe it's cleared
itself in the same way!

--
Terry, East Grinstead, UK
  #12  
Old May 24th 16, 11:15 AM posted to microsoft.public.windowsxp.general
Terry Pinnell[_3_]
external usenet poster
 
Posts: 732
Default Mysterious behaviour of RUN box

Paul wrote:

You can record video with FRAPS on Windows 7,
and from any of three render planes. This makes
FRAPS one of the most capable capture tools.


Can only speak for XP, but FRAPS cannot record desktop activity. Such
as my Run Box video example.

--
Terry, East Grinstead, UK
  #13  
Old May 24th 16, 03:07 PM posted to microsoft.public.windowsxp.general
Paul
external usenet poster
 
Posts: 18,275
Default Mysterious behaviour of RUN box

Terry Pinnell wrote:
Paul wrote:

You can record video with FRAPS on Windows 7,
and from any of three render planes. This makes
FRAPS one of the most capable capture tools.


Can only speak for XP, but FRAPS cannot record desktop activity. Such
as my Run Box video example.


The copy I tested long ago, it wants to "inject" a DLL
into every program folder on the computer. I had
a Kaspersky subscription at the time, and when the
FRAPS installer tried to run, the machine locked up
(because Kaspersky didn't like the heuristic invasion
it was seeing and put a stop to it).

The FRAPS DLL would need to be able to "filter" the
graphic command the Run Box video example generates,
in order to record them.

You would need to research whether your test case
uses annotation plane, VMR7, VMR9, some sort of
DirectX3D or whatever. Maybe this is an application
that fell through the cracks.

As I never did get FRAPS installed, I didn't have a chance
to test all planes.

If you fiddle with the rendering plane an application
uses, somethings that's enough to do capture on it.
For Adobe Flash, that means disabling Hardware
Acceleration in the little onscreen properties
box. And then your favorite GDIgrab based
application can work.

FRAPS is supposed to cover desktop video,
as well as record 3D game play. A recent competitor for
them, is the NVidia driver pack has "ShadowPlay" for
3D recording. And I don't know if ATI/AMD has any
software to compete with that or not. I don't think
the NVidia tool is intended for desktop situations.

And if it absolutely must be recorded, you can always
try a $100 video capture card, and hang it off the
HDMI connector. That's supposed to work, as long as
the I/O setup doesn't choose to use HDCP. Some cards
will have some combination of HDMI, VGA, component
video, as input options. A good card will also have
passthru, so you can watch on the monitor and see
the exact same stuff as is being recorded.

Paul
  #14  
Old May 25th 16, 06:56 AM posted to microsoft.public.windowsxp.general
No_Name
external usenet poster
 
Posts: 2
Default Mysterious behaviour of RUN box

Here's the reply Ireceived from the FRAPS developer to my email query about this:

"Thanks for your inquiry. If you are looking to record the desktop (and not in a game), then Fraps is currently able to record the 3D aero desktop in Windows 7 and Vista. Please note that for Windows Vista the aero desktop environment is only available in the Home Premium, Business and Ultimate editions.

If you have got access to a machine running one of these versions of Windows and are using the Aero desktop you can try this feature by enabling the "Monitor Aero desktop (DWM)" option under the General tab in Fraps. You will then see the framerate counter appear in a corner of the desktop and be able to take videos just like you would in a game.

Hope this helps!

Regards,
Chris Van Graas"
--------------------
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 10:24 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.