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

[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?

 

[philo]

(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.

 

[Don McCarter]

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?

 

[Robert Aldwinckle]

(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)
---

 

[Jon Kennedy]

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).

 

[Stubby]

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.

 

[Robbie Hatley]

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.

 

[Robbie Hatley]

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.

 

[N. Miller]

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.

 

[Robert Aldwinckle]

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
---

 

[Robert Aldwinckle]

(cross-post added to Winternals)

in response to me calling Windows' habit of aborting
downloads at 50KB a "bug":


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".


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."


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.

:::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.


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
---

 

[James Matthews]

Check any firewalls Etc...

--

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

(cross-post added to Winternals)

in response to me calling Windows' habit of
aborting
downloads at 50KB a "bug":


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".


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."


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.

:::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.


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