Downloads often halt at 50KB. (Attempt #2.)

[Guest Robbie Hatley]

(Second attempt. Hmmm... No responses at all to first attempt.

Ok. I'll try again. I'll also post to the IE6 group, though

I'm not really sure if this is an IE6 problem or a Win2000

problem; the two are so tightly intertwined.)

 

I've been having a problem recently on two different computers,

both running IE6 and Windows 2000 Professional: when downloading

files from the Internet, the download often stops at 50KB, with

Windows thinking that the download is complete, even if the actual

file size was 1.38MB or 11.85MB or whatever. Once this happens,

it can take many further attempts to get the download to complete.

 

I did find a partial work-around, by accident: if I empty

the temporary Internet files, the next attempt to download

the file usually succeeds. It's as if Windows sees a 50KB

file named "Fred.zip" in it's cache, says "ah-ha, the user is

attempting to download "Fred.zip", and I've already cached

that file, so I'll just give the user the cached version!"

Windows doesn't bother to check that the cached version is

COMPLETE.

 

So, what would cause Windows to think that a 50KB partial

download of an 11MB file is "complete"? (Seems like a bug.)

And why does it keep offering-up the same 50KB piece of trash

as being an 11MB file? (Seems like a second bug.)

 

Are there any workarounds for these bugs, other than emptying

the cache and trying again? That is, is there some way to

keep downloads from cutting off at the 50KB mark (it's always

almost exactly 50KB) in the first place?

 

And why 50KB? If downloads are going to fail, why not at

11.7KB or 1.53MB or whatever? Is there something magic about

this number? Some check or decision that is made at that

point?

 

--

Puzzled,

Robbie Hatley

lone wolf aatt well dott com

www dott well dott comm slant user slant lonewolf slant

[Guest philo]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

 

"Robbie Hatley" <see.my.signature@for.my.email.address> wrote in message

news:ITxWi.369774$Lx1.220755@fe05.news.easynews.com...

> (Second attempt. Hmmm... No responses at all to first attempt.

> Ok. I'll try again. I'll also post to the IE6 group, though

> I'm not really sure if this is an IE6 problem or a Win2000

> problem; the two are so tightly intertwined.)

>

> I've been having a problem recently on two different computers,

> both running IE6 and Windows 2000 Professional: when downloading

> files from the Internet, the download often stops at 50KB, with

> Windows thinking that the download is complete, even if the actual

> file size was 1.38MB or 11.85MB or whatever. Once this happens,

> it can take many further attempts to get the download to complete.

>

>

 

 

 

Unless you have your internet cache set very small,

I don't know why the problem occurs but you may want to try using a download

manager.

[Guest Don McCarter]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

I have the same kind of problem with Vista and ie7. When I attempt to

download a large

file, like a linux iso, ie7 shows a DL of 65mb.

Firefox downloads the full 3 or 4gig files.

Am I missing something in the ie7 setup?

 

 

"Robbie Hatley" <see.my.signature@for.my.email.address> wrote in message

news:ITxWi.369774$Lx1.220755@fe05.news.easynews.com...

> (Second attempt. Hmmm... No responses at all to first attempt.

> Ok. I'll try again. I'll also post to the IE6 group, though

> I'm not really sure if this is an IE6 problem or a Win2000

> problem; the two are so tightly intertwined.)

>

> I've been having a problem recently on two different computers,

> both running IE6 and Windows 2000 Professional: when downloading

> files from the Internet, the download often stops at 50KB, with

> Windows thinking that the download is complete, even if the actual

> file size was 1.38MB or 11.85MB or whatever. Once this happens,

> it can take many further attempts to get the download to complete.

>

> I did find a partial work-around, by accident: if I empty

> the temporary Internet files, the next attempt to download

> the file usually succeeds. It's as if Windows sees a 50KB

> file named "Fred.zip" in it's cache, says "ah-ha, the user is

> attempting to download "Fred.zip", and I've already cached

> that file, so I'll just give the user the cached version!"

> Windows doesn't bother to check that the cached version is

> COMPLETE.

>

> So, what would cause Windows to think that a 50KB partial

> download of an 11MB file is "complete"? (Seems like a bug.)

> And why does it keep offering-up the same 50KB piece of trash

> as being an 11MB file? (Seems like a second bug.)

>

> Are there any workarounds for these bugs, other than emptying

> the cache and trying again? That is, is there some way to

> keep downloads from cutting off at the 50KB mark (it's always

> almost exactly 50KB) in the first place?

>

> And why 50KB? If downloads are going to fail, why not at

> 11.7KB or 1.53MB or whatever? Is there something magic about

> this number? Some check or decision that is made at that

> point?

>

> --

> Puzzled,

> Robbie Hatley

> lone wolf aatt well dott com

> www dott well dott comm slant user slant lonewolf slant

>

>

[Guest Robert Aldwinckle]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

"Robbie Hatley" <see.my.signature@for.my.email.address> wrote in message

news:ITxWi.369774$Lx1.220755@fe05.news.easynews.com...

> (Second attempt. Hmmm... No responses at all to first attempt.

> Ok. I'll try again. I'll also post to the IE6 group, though

> I'm not really sure if this is an IE6 problem or a Win2000

> problem; the two are so tightly intertwined.)

>

> I've been having a problem recently on two different computers,

> both running IE6 and Windows 2000 Professional: when downloading

> files from the Internet, the download often stops at 50KB, with

> Windows thinking that the download is complete, even if the actual

> file size was 1.38MB or 11.85MB or whatever. Once this happens,

> it can take many further attempts to get the download to complete.

>

> I did find a partial work-around, by accident: if I empty

> the temporary Internet files, the next attempt to download

> the file usually succeeds. It's as if Windows sees a 50KB

> file named "Fred.zip" in it's cache, says "ah-ha, the user is

> attempting to download "Fred.zip", and I've already cached

> that file, so I'll just give the user the cached version!"

> Windows doesn't bother to check that the cached version is

> COMPLETE.

>

> So, what would cause Windows to think that a 50KB partial

> download of an 11MB file is "complete"? (Seems like a bug.)

 

 

Not necessarily. If it is cached, depending on your cache-checking

options, IE might not even check with the server. Even if it did check

with the server, there might be an intermediate cache which would respond

and then if it confirmed the validity of the cached item IE could use it

with no further downloading.

 

> And why does it keep offering-up the same 50KB piece of trash

> as being an 11MB file? (Seems like a second bug.)

 

 

Not necessarily. Downloading files often occurs in two steps,

the first step to identify the file and then the second to actually

complete the download. E.g. the first is what happens before

a download prompt is shown to the user.

 

>

> Are there any workarounds for these bugs, other than emptying

> the cache and trying again? That is, is there some way to

> keep downloads from cutting off at the 50KB mark (it's always

> almost exactly 50KB) in the first place?

 

 

Is it really being cached or just downloaded into the TIF?

You could check on what is really happening use FileMon (or ProcMon)

filtering on Temp and also by using FiddlerTool to see if cache-checking

is actually being done. If it is you should at least set the option to Every visit...

to avoid the possibility of the cached copy being used with no attempt at

redownloading a file of the same name.

 

>

> And why 50KB? If downloads are going to fail, why not at

> 11.7KB or 1.53MB or whatever? Is there something magic about

> this number? Some check or decision that is made at that

> point?

 

 

Fiddler might help explain that. ; )

 

 

Good luck

 

Robert Aldwinckle

(posting from IE6.browser)

---

[Guest Jon Kennedy]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

Instead of just emptying the TIF folder, delete it entirely from another

user account with admin. privileges. It will be recreated as empty upon

rebooting. This will get that folder's hidden index.dat file that can

become bloated - it's not reset when emptying the TIF folder via IE's

Internet Options.

http://www.mvps.org/winhelp2002/delcache.htm - or use a third-party tool

like CCleaner as mentioned on that site to totally nuke your TIF (make sure

you select its index.dat option).

--

 

Jon Kennedy, MS MVP/IE

Charlotte, NC, USA

jkennedy2@carolina.rr.com

 

 

"Robbie Hatley" <see.my.signature@for.my.email.address> wrote in message

news:ITxWi.369774$Lx1.220755@fe05.news.easynews.com...

> (Second attempt. Hmmm... No responses at all to first attempt.

> Ok. I'll try again. I'll also post to the IE6 group, though

> I'm not really sure if this is an IE6 problem or a Win2000

> problem; the two are so tightly intertwined.)

>

> I've been having a problem recently on two different computers,

> both running IE6 and Windows 2000 Professional: when downloading

> files from the Internet, the download often stops at 50KB, with

> Windows thinking that the download is complete, even if the actual

> file size was 1.38MB or 11.85MB or whatever. Once this happens,

> it can take many further attempts to get the download to complete.

>

> I did find a partial work-around, by accident: if I empty

> the temporary Internet files, the next attempt to download

> the file usually succeeds. It's as if Windows sees a 50KB

> file named "Fred.zip" in it's cache, says "ah-ha, the user is

> attempting to download "Fred.zip", and I've already cached

> that file, so I'll just give the user the cached version!"

> Windows doesn't bother to check that the cached version is

> COMPLETE.

>

> So, what would cause Windows to think that a 50KB partial

> download of an 11MB file is "complete"? (Seems like a bug.)

> And why does it keep offering-up the same 50KB piece of trash

> as being an 11MB file? (Seems like a second bug.)

>

> Are there any workarounds for these bugs, other than emptying

> the cache and trying again? That is, is there some way to

> keep downloads from cutting off at the 50KB mark (it's always

> almost exactly 50KB) in the first place?

>

> And why 50KB? If downloads are going to fail, why not at

> 11.7KB or 1.53MB or whatever? Is there something magic about

> this number? Some check or decision that is made at that

> point?

>

> --

> Puzzled,

> Robbie Hatley

> lone wolf aatt well dott com

> www dott well dott comm slant user slant lonewolf slant

>

>

[Guest Stubby]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

Look at your network software (OS) configuration. Frequently they impose a

limit on the size of file transfers. SMTP and mail related software can do

this also in an attempt to inhibit spammers.

 

 

"Jon Kennedy" <jkennedy2@carolina.rr.com> wrote in message

news:exjTvOZHIHA.3768@TK2MSFTNGP06.phx.gbl...

> Instead of just emptying the TIF folder, delete it entirely from another

> user account with admin. privileges. It will be recreated as empty upon

> rebooting. This will get that folder's hidden index.dat file that can

> become bloated - it's not reset when emptying the TIF folder via IE's

> Internet Options.

> http://www.mvps.org/winhelp2002/delcache.htm - or use a third-party tool

> like CCleaner as mentioned on that site to totally nuke your TIF (make

sure

> you select its index.dat option).

> --

>

> Jon Kennedy, MS MVP/IE

> Charlotte, NC, USA

> jkennedy2@carolina.rr.com

>

>

> "Robbie Hatley" <see.my.signature@for.my.email.address> wrote in message

> news:ITxWi.369774$Lx1.220755@fe05.news.easynews.com...

> > (Second attempt. Hmmm... No responses at all to first attempt.

> > Ok. I'll try again. I'll also post to the IE6 group, though

> > I'm not really sure if this is an IE6 problem or a Win2000

> > problem; the two are so tightly intertwined.)

> >

> > I've been having a problem recently on two different computers,

> > both running IE6 and Windows 2000 Professional: when downloading

> > files from the Internet, the download often stops at 50KB, with

> > Windows thinking that the download is complete, even if the actual

> > file size was 1.38MB or 11.85MB or whatever. Once this happens,

> > it can take many further attempts to get the download to complete.

> >

> > I did find a partial work-around, by accident: if I empty

> > the temporary Internet files, the next attempt to download

> > the file usually succeeds. It's as if Windows sees a 50KB

> > file named "Fred.zip" in it's cache, says "ah-ha, the user is

> > attempting to download "Fred.zip", and I've already cached

> > that file, so I'll just give the user the cached version!"

> > Windows doesn't bother to check that the cached version is

> > COMPLETE.

> >

> > So, what would cause Windows to think that a 50KB partial

> > download of an 11MB file is "complete"? (Seems like a bug.)

> > And why does it keep offering-up the same 50KB piece of trash

> > as being an 11MB file? (Seems like a second bug.)

> >

> > Are there any workarounds for these bugs, other than emptying

> > the cache and trying again? That is, is there some way to

> > keep downloads from cutting off at the 50KB mark (it's always

> > almost exactly 50KB) in the first place?

> >

> > And why 50KB? If downloads are going to fail, why not at

> > 11.7KB or 1.53MB or whatever? Is there something magic about

> > this number? Some check or decision that is made at that

> > point?

> >

> > --

> > Puzzled,

> > Robbie Hatley

> > lone wolf aatt well dott com

> > www dott well dott comm slant user slant lonewolf slant

> >

> >

>

>

[Guest Robbie Hatley]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

 

"Robert Aldwinckle" wrote in response to me calling Windows' habit of aborting

downloads at 50KB a "bug":

> Not necessarily.

 

My definition of "bug" is obviously more pragmatic than yours. :-) For me, any

aspect of a software's behavior which is other than what I desire is a "bug".

But I suppose one man's "bug" may be another's "feature".

> If it is cached, depending on your cache-checking

> options, IE might not even check with the server. Even if it did check

> with the server, there might be an intermediate cache which would respond

> and then if it confirmed the validity of the cached item IE could use it

> with no further downloading.

 

I see what you mean. I just changed IE to check for new versions of file on every

visit to a page. (It was set on "auto", which isn't really what I want when downloading

software.)

 

It's still a "bug", though. It's a conceptual bug. A truly smart operating system

would think, "Hmmm... this is file is software as opposed to pictures or text,

so I shouldn't using caching at all, even though the user specified 'auto' mode. I'll

do what he means, not what he says."

> Is it really being cached or just downloaded into the TIF?

 

I thought the two were the same. I always thought the folder

C:\Docs-n-sttngs\UserName\Local Settings\Tmp-Intrnt-Files\content.ie5

was the "cache", and also the "Temporary Internet Files". So, what do

you mean by "cache", and what do you mean by "TIF"?

> You could check on what is really happening use FileMon (or ProcMon)

> filtering on Temp

 

:::Googles FileMon:::

 

Hmmm.... that's obsolete for Win2KSP4; it's superseded by ProcMon

 

:::downloads, installs ProcMon:::

 

Cool, I got a BSOD "KMODE_EXCEPTION_NOT_HANDLED in fltmgr.sys"

the first time I tried to install that. I rebooted Win2K, turned off my

firewall, anti-virus, and anti-spyware, and tried again. Worked. My,

i see about 5000 system events happening each second, the vast

majority of them avgas.exe (AVG anti-spyware). Even though it's "off",

the TSR part is hogging CPU time by reading the registry once every

few milliseconds. I completely exited from that. Many fewer events now.

 

Cool program; thanks for the tip. I'll have to play around with that some

more when I have more time, and see what all it can do.

> and also by using FiddlerTool to see if cache-checking

> is actually being done. If it is you should at least set the option to Every visit...

> to avoid the possibility of the cached copy being used with no attempt at

> redownloading a file of the same name.

 

Ok, I'll check that out later. Thanks for the tip.

 

--

Cheers,

Robbie Hatley

lonewolf aatt well dott com

www dott well dott com slant user slant lonewolf slant

[Guest Robbie Hatley]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

 

"Jon Kennedy" wrote:

> Instead of just emptying the TIF folder, delete it entirely from another

> user account with admin. privileges. It will be recreated as empty upon

> rebooting. This will get that folder's hidden index.dat file that can

> become bloated - it's not reset when emptying the TIF folder via IE's

> Internet Options.

 

Good point. I'll try that. Thanks for the tip.

 

--

Cheers,

Robbie Hatley

lonewolf aatt well dott com

www dott well dott com slant user slant lonewolf slant

[Guest N. Miller]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

On Wed, 21 Nov 2007 23:04:56 -0800, Robbie Hatley wrote:

> My definition of "bug" is obviously more pragmatic than yours. :-) For me, any

> aspect of a software's behavior which is other than what I desire is a "bug".

 

I thought that a "bug" was any aspect of an application's behavior which was

not as expected, or designed. If your desire does not match the constraints

of the software, it isn't a "bug", just a failure to function as desired;

assuming that you are just an end user.

 

--

Norman

~Shine, bright morning light,

~now in the air the spring is coming.

~Sweet, blowing wind,

~singing down the hills and valleys.

[Guest Robert Aldwinckle]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

"N. Miller" <anonymous@msnews.aosake.net> wrote in message

news:1v25rrvl19wrg.dlg@msnews.aosake.net...

> On Wed, 21 Nov 2007 23:04:56 -0800, Robbie Hatley wrote:

>

>> My definition of "bug" is obviously more pragmatic than yours. :-) For me, any

>> aspect of a software's behavior which is other than what I desire is a "bug".

>

> I thought that a "bug" was any aspect of an application's behavior which was

> not as expected, or designed. If your desire does not match the constraints

> of the software, it isn't a "bug", just a failure to function as desired;

> assuming that you are just an end user.

 

 

Exactly. Or more baldly stated, a "bug" is something which happens

which doesn't match the specs (which the end user is never allowed to see.)

Sometimes "bugs" are corrected by documenting their actual behaviour.

Anything else would be resolved as a "User Error", "Working as designed"

or an "Enhancement request".

 

BTW some software companies have dropped the term "bug" and substituted

"defect". But they are still unlikely to categorize deficiencies in functionality

as defects.

 

 

; )

 

Robert

---

[Guest Robert Aldwinckle]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

(cross-post added to Winternals)

"Robbie Hatley" <lonewolf@well.com> wrote in message

news:-4idne0w94VERtranZ2dnUVZ_j6dnZ2d@giganews.com...

>

> "Robert Aldwinckle" wrote in response to me calling Windows' habit of aborting

> downloads at 50KB a "bug":

>

>> Not necessarily.

>

> My definition of "bug" is obviously more pragmatic than yours. :-) For me, any

> aspect of a software's behavior which is other than what I desire is a "bug".

> But I suppose one man's "bug" may be another's "feature".

>

>> If it is cached, depending on your cache-checking

>> options, IE might not even check with the server. Even if it did check

>> with the server, there might be an intermediate cache which would respond

>> and then if it confirmed the validity of the cached item IE could use it

>> with no further downloading.

>

> I see what you mean. I just changed IE to check for new versions of file on every

> visit to a page. (It was set on "auto", which isn't really what I want when downloading

> software.)

>

> It's still a "bug", though. It's a conceptual bug. A truly smart operating system

> would think, "Hmmm... this is file is software as opposed to pictures or text,

> so I shouldn't using caching at all, even though the user specified 'auto' mode. I'll

> do what he means, not what he says."

>

>> Is it really being cached or just downloaded into the TIF?

>

> I thought the two were the same. I always thought the folder

> C:\Docs-n-sttngs\UserName\Local Settings\Tmp-Intrnt-Files\content.ie5

> was the "cache", and also the "Temporary Internet Files". So, what do

> you mean by "cache", and what do you mean by "TIF"?

 

 

Cached in the sense that the server has labeled it with an Etag.

Even if a file is marked non-cacheable it still has to go somewhere temporarily.

You could check for Etag using Fiddler but watch what happens to the files

once they are received using FileMon.

 

>

>> You could check on what is really happening use FileMon (or ProcMon)

>> filtering on Temp

>

> :::Googles FileMon:::

>

> Hmmm.... that's obsolete for Win2KSP4; it's superseded by ProcMon

>

> :::downloads, installs ProcMon:::

>

> Cool, I got a BSOD "KMODE_EXCEPTION_NOT_HANDLED in fltmgr.sys"

> the first time I tried to install that.

 

 

I'm glad I didn't recommend ProcMon. <eg>

I never had that symptom with FileMon.

Another reason I would prefer FileMon is because it is much easier

to set and use its filters than to set and use ProcMon's filters IMO.

The best things about ProcMon is that you can integrate the tracing

of both RegMon and FileMon and save traces for subsequent

comparative analysis. With the older products you had to try to correlate

trace records using their timestamps and once captured all you had was

an unweildy text file.

 

BTW that isn't the only BSOD you may see with ProcMon.

I was also getting STOP 8E in procmon11.sys.

I noticed that a new version came out in early November

and haven't seen that other crash so far with it but I do still get

the 7E one that (I assume) you got.[1] Those crashes have certainly

made me more cautious about saving stuff before I start using ProcMon. ; )

 

[1] These things don't appear in the event log and I have never written their

details down, so I may have them backwards. All I can remember for sure

is that I have had BSOD in both fltmgr.sys and procmon11.sys with codes

7E and 8E.

 

> I rebooted Win2K, turned off my

> firewall, anti-virus, and anti-spyware, and tried again. Worked. My,

> i see about 5000 system events happening each second, the vast

> majority of them avgas.exe (AVG anti-spyware). Even though it's "off",

> the TSR part is hogging CPU time by reading the registry once every

> few milliseconds. I completely exited from that. Many fewer events now.

>

> Cool program; thanks for the tip. I'll have to play around with that some

> more when I have more time, and see what all it can do.

>

>> and also by using FiddlerTool to see if cache-checking

>> is actually being done. If it is you should at least set the option to Every visit...

>> to avoid the possibility of the cached copy being used with no attempt at

>> redownloading a file of the same name.

>

> Ok, I'll check that out later. Thanks for the tip.

 

 

You will be pleased to know that so far I have had no crashes with it... ; )

 

>

> --

> Cheers,

> Robbie Hatley

> lonewolf aatt well dott com

> www dott well dott com slant user slant lonewolf slant

 

 

Good luck

 

Robert

---

[Guest James Matthews]

Re: Downloads often halt at 50KB. (Attempt #2.)

 

Check any firewalls Etc...

 

--

 

http://search.goldwatches.com/?Search=Movado+Watches

http://www.goldwatches.com/

http://www.jewelerslounge.com/

"Robert Aldwinckle" <robald@techemail.com> wrote in message

news:uTUdsUvLIHA.536@TK2MSFTNGP06.phx.gbl...

> (cross-post added to Winternals)

> "Robbie Hatley" <lonewolf@well.com> wrote in message

> news:-4idne0w94VERtranZ2dnUVZ_j6dnZ2d@giganews.com...

>>

>> "Robert Aldwinckle" wrote in response to me calling Windows' habit of

>> aborting

>> downloads at 50KB a "bug":

>>

>>> Not necessarily.

>>

>> My definition of "bug" is obviously more pragmatic than yours. :-) For

>> me, any

>> aspect of a software's behavior which is other than what I desire is a

>> "bug".

>> But I suppose one man's "bug" may be another's "feature".

>>

>>> If it is cached, depending on your cache-checking

>>> options, IE might not even check with the server. Even if it did check

>>> with the server, there might be an intermediate cache which would

>>> respond

>>> and then if it confirmed the validity of the cached item IE could use it

>>> with no further downloading.

>>

>> I see what you mean. I just changed IE to check for new versions of file

>> on every

>> visit to a page. (It was set on "auto", which isn't really what I want

>> when downloading

>> software.)

>>

>> It's still a "bug", though. It's a conceptual bug. A truly smart

>> operating system

>> would think, "Hmmm... this is file is software as opposed to pictures or

>> text,

>> so I shouldn't using caching at all, even though the user specified

>> 'auto' mode. I'll

>> do what he means, not what he says."

>>

>>> Is it really being cached or just downloaded into the TIF?

>>

>> I thought the two were the same. I always thought the folder

>> C:\Docs-n-sttngs\UserName\Local Settings\Tmp-Intrnt-Files\content.ie5

>> was the "cache", and also the "Temporary Internet Files". So, what do

>> you mean by "cache", and what do you mean by "TIF"?

>

>

> Cached in the sense that the server has labeled it with an Etag.

> Even if a file is marked non-cacheable it still has to go somewhere

> temporarily.

> You could check for Etag using Fiddler but watch what happens to the files

> once they are received using FileMon.

>

>

>>

>>> You could check on what is really happening use FileMon (or ProcMon)

>>> filtering on Temp

>>

>> :::Googles FileMon:::

>>

>> Hmmm.... that's obsolete for Win2KSP4; it's superseded by ProcMon

>>

>> :::downloads, installs ProcMon:::

>>

>> Cool, I got a BSOD "KMODE_EXCEPTION_NOT_HANDLED in fltmgr.sys"

>> the first time I tried to install that.

>

>

> I'm glad I didn't recommend ProcMon. <eg>

> I never had that symptom with FileMon.

> Another reason I would prefer FileMon is because it is much easier

> to set and use its filters than to set and use ProcMon's filters IMO.

> The best things about ProcMon is that you can integrate the tracing

> of both RegMon and FileMon and save traces for subsequent

> comparative analysis. With the older products you had to try to

> correlate

> trace records using their timestamps and once captured all you had was

> an unweildy text file.

>

> BTW that isn't the only BSOD you may see with ProcMon.

> I was also getting STOP 8E in procmon11.sys.

> I noticed that a new version came out in early November

> and haven't seen that other crash so far with it but I do still get

> the 7E one that (I assume) you got.[1] Those crashes have certainly

> made me more cautious about saving stuff before I start using ProcMon.

> ; )

>

> [1] These things don't appear in the event log and I have never written

> their

> details down, so I may have them backwards. All I can remember for sure

> is that I have had BSOD in both fltmgr.sys and procmon11.sys with codes

> 7E and 8E.

>

>

>> I rebooted Win2K, turned off my

>> firewall, anti-virus, and anti-spyware, and tried again. Worked. My,

>> i see about 5000 system events happening each second, the vast

>> majority of them avgas.exe (AVG anti-spyware). Even though it's "off",

>> the TSR part is hogging CPU time by reading the registry once every

>> few milliseconds. I completely exited from that. Many fewer events

>> now.

>>

>> Cool program; thanks for the tip. I'll have to play around with that

>> some

>> more when I have more time, and see what all it can do.

>>

>>> and also by using FiddlerTool to see if cache-checking

>>> is actually being done. If it is you should at least set the option to

>>> Every visit...

>>> to avoid the possibility of the cached copy being used with no attempt

>>> at

>>> redownloading a file of the same name.

>>

>> Ok, I'll check that out later. Thanks for the tip.

>

>

> You will be pleased to know that so far I have had no crashes with it...

> ; )

>

>

>>

>> --

>> Cheers,

>> Robbie Hatley

>> lonewolf aatt well dott com

>> www dott well dott com slant user slant lonewolf slant

>

>

> Good luck

>

> Robert

> ---

>

>