none
MSDN downloads "interrupted" and cannot resume after HOURS of downloading already RRS feed

  • General discussion

  • I used to be able to download LARGE FILES from MSDN by using the 'download manager'. But NOW I see that this has been DISCONTINUED.

    I know, it was a 'total hack' to use it with newer browsers.  You had to go into EMULATION MODE and indicate you were IE9 or earlier.  And THEN it would work.

    BUT IT WORKED!

    NOW whenever I try to download a file [let's say a Windows 10 ISO image so I can install it to test my windows applications], I get "download interrupted" and *NO* *WAY* *TO* *CONTINUE*.

    That's right.  I get to START ALL OVER AGAIN, and WASTE WHATEVER TIME IT WAS that downloaded the first 980MB of the 4G file (or whatever).

    It's pretty SAD that things would have to go this way, you know?

    Am I in "the ghetto" or something because MY! INTERNET! CONNECTION! IS! NOT! LIGHTNING! FAST! ???  Am I getting *UNEQUAL* *TREATMENT* here?  A *BUSINESS CONNECTION* is *EXPENSIVE* you know.  I need money to *AFFORD* my *MSDN SUBSCRIPTION*.  SOMETHING has to go.  I guess I won't be having *LIGHTNING* *FAST* *INTERNET*.

    But would it even WORK if my connection *WERE* lightning fast?

    Taking away the ONLY method I could POSSIBLY use to make this work, back in APRIL, with NO WARNINGS AT ALL, is just *SICK* as far as *I* am concerned.

    What kind of CUSTOMER SUPPORT IS THIS?

    But you know, I think  I have a good idea what is happening:  my login is expiring!

    SO, as long as there's *ACTIVITY* on the connection, just tell your "session manager" thingy to KEEP THE LOGIN ALIVE!

    When you get re-directed to the login, the browser's download manager thinks the file header is corrupted, and WILL! NOT! CONTINUE! FROM! WHERE! IT! LEFT! OFF!!!  In other words, pause/resume is COMPLETELY FUBAR.

    Microsoft, FIX THIS NOW!  It's not THAT hard.  I just told you what the problem is.  NOW FIX IT!


    Oh, one more thing - I went to the 'support' page to try and get online support for this, but "MSDN download" isn't in the list of products.  Yeah, THAT helped, too.  NOT.
    Saturday, August 29, 2015 2:43 PM

All replies

  • well, it looks like doing additional research may have paid off. Or not.

    Officially, Microsoft doesn't support "3rd party download managers".

    There is a FIREFOX ADDON that comes well recommended.

    https://addons.mozilla.org/en-US/firefox/addon/downthemall/developers

    THIS may do what I need.  I'm still testing it, but at ~800m which isn't quite as far as I got before.

    SO, the solution may be to:

    a) click on 'details' so you can get the 'direct link'

    b) open FIREFOX [after installing the plugin], and paste in the link

    c) at the 'what to do with this file' prompt, pick 'DownThemAll' and save it where you want it to go

    I am somewhat SADDENED that Microsoft couldn't do this in their OWN browsers properly.

    post-edit note:  it failed after several hours, with a "403 error".  No joy.  No file.  I'm getting rather FRUSTRATED with all of this.

    Sunday, August 30, 2015 6:07 AM
  • MICROSOFT:  you *KNOW* that there are *SEVERAL* RFC standard protocols out there that are SECURE ENOUGH to prevent people from "ripping off" your proprietary subscriber-only content, right?

    So WHY can't I use something like:

    a) git

    b) scp, sftp, or rsync

    c) a standard HTTPS-based protocol that allows "byte ranges" and does NOT time out while there's activity

    OR - maybe you can just publish "pieces" of the files, and we download it in CHUNKS, and re-assemble them on our end?

    OR - you encode our MSDN ID and IP address into the URL with a hash so that if the file name and MSDN ID and IP address don't match the hash, we can't get the file.  THAT WAY the link would CONTINUE to work, regardless of the 'live.com' login status.  And if our subscription expires, the server would know that.  Just store the hash in a database someplace and do a lookup of "all of that" based on the hash, deliver the correct content, and control whether or not we can download it *THAT* way.

    THAT would be *SIMPLE*.  That's how *I* would do it.  And a proper hash would be generated by YOUR web servers when I get the 'direct download link'.  And it would ONLY work for ME from THIS IP address.  And you could auto-delete them after a MONTH or something, more than enough time to download the files.  Whatever.  It's not like 1 record in a database where I only download stuff a few times a year would ever really matter THAT much, ya know?

    The WHOLE POINT HERE is that you DO NOT HAVE TO DO IT in such a "retentive" way as to ALLOW THE SESSION TO TIME OUT, WHILE THERE IS TRAFFIC, CAUSING A 403 ERROR, AND PREVENTING PEOPLE LIKE ME FROM BEING ABLE TO EVEN *USE* OUR SUBSCRIPTION, AFTER YOU INTENTIONALLY "BROKE IT" by REMOVING SUPPORT FOR THE ONLY METHOD THAT *DID* WORK!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Sunday, August 30, 2015 6:34 PM
  • I understand your frustration at not being able to download. Please contact the MSDN Subscriptions Customer Service at http://msdn.microsoft.com/en-US/subscriptions/aa948874 and they should be able to assist you with the downloads.

    Thanks,
    Sowmya
    MSDN Subscriptions Feedback



    Sowmya MSDN Subscription Feedback

    Monday, August 31, 2015 11:26 PM
  • Thanks, I'm trying to get this (case ID 9001247534) escalated, but I'm running into problems NOW trying to get 'PSR.EXE' to work.  several hours (half a day even) of downloading to the point of failure, able to DEMONSTRATE the failure, and then I go to save the info with 'PSR' and guess what?  I get this dialog box that says "An error occurred while trying to save the recorded steps" or something like that.

    And from the feedback I got, they can't "escalate" this without a PSR report!!!

    I played with PSR for a while, discovered that just a single click on a window after I start recording was enough to cause this thing to NOT save the file.  "Do nothing" and it doesn't try to save anything (because it's empty).

    So I replied via e-mail asking them to PLEASE escalate it ANYWAY, because PSR won't work.  I gave them screenshots showing EVERYTHING, from the MSDN download page, to the size of the file, and the messages that IE 11 gave me at the end of the download.

    I *HOPE* this isn't a case of "Catch 22" or Vogon bureaucracy.

    I did find a possible solution to PSR's problem, though.  I really don't want to go there.  It involves uninstalling two patches that correct privilege elevation security problems in Windows 7.

    http://superuser.com/questions/960297/psr-an-error-occurred-while-attempting-to-save-the-recorded-steps

    So it's NOT just me having this problem.

    And NOW I need a fix to PSR, so I can download things from MSDN.  This is getting rather pathetic...

    Friday, September 4, 2015 4:04 PM
  • Ah, looks like the MSDN troubleshooters are on top of this now.  Got the 'escalation' (yay!) and did a repro of the problem, sent screenshots and descriptions back to MSDN [as requested] using a *special* login ID [my guess is they track everything that happens with it].

    Let's all hope this gets resolved now!
    Saturday, September 5, 2015 6:35 PM
  • I have raised this issue already on Feb 2015 but I have got a reply stating that They have noted my feedback. Let's hope to get this fixed already.

    https://social.msdn.microsoft.com/Forums/en-US/2cc7977f-fd78-497c-a411-54f78a2c6e87/downloading-multiple-files-one-by-one?forum=msdnfeedback

    Ultimately, Microsoft FTM or similar alternative download manager should come back. Hope MSDN are working on this 

    Thanks
    prathaprabhu

    Monday, September 7, 2015 3:26 AM
  • Hello there, I am also having the same issue of resuming my Visual Studio ISO Download but here is the twist, I have also tried downloading without interruption but after completing 90% of it, the download automatically issued an access denied error in my Download Manager. I've also contacted Microsoft DreamSpark support but nothing has been solved even after 10 days. Kindly, help me out on this, as this issue is getting rather frustrating.
    • Edited by ar27111994 Sunday, September 20, 2015 12:29 PM
    Sunday, September 20, 2015 12:28 PM
  • Since the issue is with downloading the Visual Studio from your DreamSpark subscription, your best bet is to contact the MSDN Subscriptions Customer Service at http://msdn.microsoft.com/en-US/subscriptions/aa948874 

    Thanks,
    Sowmya
    MSDN Subscriptions Feedback


    Sowmya MSDN Subscription Feedback

    Monday, September 21, 2015 10:04 PM
  • well, after a MONTH of escalation, having "boiler plate" tossed my way several times, and having provided CONCLUSIVE PROOF of what is REALLY going on, apparently the engineers "have everything" (or so I've been told) and are "working on it".

    It's been over a MONTH.

    OK, THIS is the situation as I have proved using wireshark captures and multiple methods of downloading.

    1.  when you download something, the login screen and file redirectors create a URL for the file you want to download at 'download.msdn.microsoft.com', with 3 parameters in the URL.  You can see it via a 'wireshark' capture.

    2.  NOT specifying these 3 parameters in the URL gets you a '403: Forbidden' error.

    3.  Using "old parameters" (more than about 10 hours old) ALSO gets you a '403: Forbidden' error.

    4.  Trying to use this URL for MORE THAN 10 HOURS will *ALSO* get you the same "403: Forbidden' error.  In other words, the security context that is created is for a FIXED LENGTH OF TIME, not NEARLY long enough to download files more than 1Gb in size without a FAST internet connection.

    5.  If you retrieve a NEW URL, you might be able to 'pick up where you left off', except that the server at download.msdn.microsoft.com does not PROPERLY handle a 'Range' header.  It won't accept a range formatted as "12345-" which is supposed to mean "through the rest of the file".  You must actually specify a byte range.  This is NOT RFC COMPLIANT!

    6.  Downloads stop after about 4 hours and 51 minutes of traffic, more often than not.  The "stoppage" is caused by a FIN packet sent BY THE SERVER, which actually CLOSES the TCP connection.  Some downloaders may successfully get one more 4 hours and 51 minutes' worth of data by use of a 'Range' header.  THEN, after THAT expires, you get '403: Forbidden' errors.

    A TOTAL HACK METHOD may be possible.  To make this work you'd have to do the following:

    a) determine the total length of the file in bytes.

    b) break the file up into individual 'Range' values manually, with sizes that can be downloaded in under 4 hours and 51 minutes.

    c) for each 'range', get a fresh URL (logging in again, attempt a download, and capture that URL's ACTUAL address via 'wireshark', and immediately stop the transfer within the browser so you don't waste precious bandwidth).

    d) use 'curl' or some similar utility to download JUST THE SEGMENT YOU WANT, naming it appropriately so you can re-assemble it.

    e) repeat this process until you have all of the file sections.  THEN, assemble them together with a binary copy.

    f) validate the SHA1 and file size

    This is the ONLY method I can think of that might actually work.  I have NOT tried it yet, but so far it looks as if it MIGHT work.

    This involves WIRESHARK tracing the activity and grabbing the "actual URL" from the re-directed request, along with the 3 parameters.

    Microsoft could EASILY fix this by doing TWO things:

    a) STOP the server from disconnecting automatically after 4 hours and 51 minutes

    b) change the default timeout from 10 hours to at least 48 hours.

    and optionally

    c) fix the Range header problem on the server, by being RFC compliant.

    Doing 'b' and 'c' but not 'a' might actually work, using a download manager or 'wget' on a 'hacked' URL.

    doing 'b' is ABSOLUTELY NECESSARY, however.

    NOTE:  I don't have to re-state just how *FRUSTRATING* this entire process has been.  I have done EVERYTHING I can to draw the lines from A to B to C so that even the MOST CASUAL OBSERVER will conclude that the problem IS where it is, that is, Microsoft's security context timing out coupled with automatic connection terminations at 4 hours and 51 minutes, along with improper implementation of the 'Range' header [so that 3rd party utilities and downloaders won't work properly].

    So it's *NOT* my network, as the Vogon bureaucracy would INSTANTLY assume.  I don't need a "fake account" to test the downloading on.  I don't need to "contact my ISP".  I don't need to "try it with a different network".  YOU guys at Microsoft *NEED* *TO* *FIX* *YOUR* *SERVERS*, or else provide us with a RELIABLE "non-ActiveX" utility that can do what I mentioned in the 'hack' section, and thereby allow those of us with LESS THAN 3Gbit connections to actually be able to USE OUR MSDN SUBSCRIPTIONS like we USED to be able to do, before last March, when you ABANDONED the ONLY means by which we could SUCCESSFULLY and RELIABLY download!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    I shouldn't have to point out that a business connection that gets me 1.5Mbits would cost me an extra $50/month.  I shouldn't have to point out that a similar connection that gets me 3Gbits would be $50 more a month.  Must I pay an extra $100/month for a connection that can download the files?  NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  And what changes would be coming down the pike NEXT YEAR?  From the way things look, you're IGNORING the Customer's needs and desires!  Please STOP doing that!


    Tuesday, October 13, 2015 7:05 PM
  • see the "possible hack" in the post (above) that I did just a minute or two before this one

    If I can come up with a RELIABLE way of getting through the re-directs of the login screen, *MAYBE* I can write a hack that will allow downloading.  But if I do this, it will use POSIX utilities like 'curl' and 'nc' and 'bash'.


    Tuesday, October 13, 2015 7:15 PM
  • Hi, can you at LEAST help address the OBVIOUS download problems the REST of us are having?  I outlined EXACTLY what is happening in my earlier post, above.  It's the server at 'download.msdn.microsoft.com' that TIMES OUT after 4 hours and 51 minutes, and CLOSES the TCP connection, REGARDLESS of whether or not there is traffic flowing on it.  Then after about 10 hours, the URL with the 3 parameters (that you receive via the download button or whatever) TIMES OUT and you THEN get "403: Forbidden" errors if you try to resume the download.

    Additionally, the 'Range' header isn't implemented properly on the server at download.msdn.microsoft.com - it does not handle ranges that end in '-'.  It's NOT RFC COMPLIANT.

    [I have sent all of this info in my 'escalation' but of course, I have to SCREAM BLOODY HECK or something to get this resolved in any TIMELY MANNER, it seems, and get past the VOGON BUREAUCRACY that's slowing things down to a crawl]

    it's Priority Support Case ID # 9001247534 if there are any questions.  A month and a half is pretty SLOW getting this resolved.  And one other commentor in this thread has been trying since FEBRUARY!  Why is this TAKING so LONG?  It's not like I haven't GIVEN YOU THE EXACT PROBLEM on a SILVER PLATE or anything, nor drawn the lines from A to B to C so that you can see it EVER so clearly, or anything... but yeah, I *HAVE* done that!

    4 hours and 51 minutes.  Then disconnect.  That's repeatable.

    Tuesday, October 13, 2015 7:22 PM
  • Hello big bad bombastic bob,

    The MSDN subscribers download issue has already been notified to the relevant team and they are working to fix it. Please do understand that changes has to be made globally, so it requires enough time for them to investigate and implement the new features or introduce a new download manager like FTM.

    Thanks
    prathaprabhu


    Wednesday, October 14, 2015 2:52 AM
  • thanks, I'm glad they're on it, but it's December now and still, well, NOTHING.


    Wednesday, December 9, 2015 7:57 PM
  • I suppose they are still working on it, I will once again check with the relevant team and get back to you.

    Thanks
    prathaprabhu


    Don't Say Can't Say Can to Not

    Saturday, January 16, 2016 1:50 AM
  • Well, it's APRIL, and *STILL* nothing.

    I need to download the checked build of windows 7 to assist me with developing a device driver.  YES, I'm doing it for Windows 7, because that's what I use.  It's also what MORE THAN HALF OF WINDOWS USERS are using.

    Unfortunately, the checked images are "all in one" and it's 3Gb for the 64-bit version, and 2Gb for the 32-bit version.

    So again, I attempt to download the image, and the download stops after 1.4Gb.

    MICROSOFT, YOU NEED TO FIX THIS [insert profanity here] PROBLEM IMMEDIATELY!  THIS HAS GONE ON WAY! TOO! LONG! and it's like you're saying (think 'under 25 person' saying this), "Dude, you need to GET a PROPER CONNECTION".

    Well, a FASTER CONNECTION eats into my BUSINESS BUDGET too much.  If I have to do THAT, I won't be able to AFFORD the MSDN RENEWAL.  get it???

    business connections cost WAY more than home connections, PARTICULARLY if you need a fixed IP address (to run a mail server, DNS server, VPN or other remote access) and things like that.

    "Get with the 21st century you old fogie" isn't an acceptable ATTITUDE, and it seems (to me) *THIS* is what you're implying by *NOT* fixing this problem!!!  Really, *ALL* you have to do is INCREASE THE LOGIN TIMEOUT to 24 hours (or more).  Even 12 hours would help.  And the download shouldn't terminate after 4 hours and 51 minutes, either.

    Tuesday, April 5, 2016 6:20 PM
  • This just got WORSE.

    In a response to an e-mail that SIMPLY REMINDS MICROSOFT that THIS PROBLEM STILL EXISTS, they said:

    "Thank you for your email; however, according to my engineering team and based on all possible scenarios, this seems to be only affecting you."

    WRONG!!!  (a simple search in THIS forum shows this problem has been around for *YEARS*, and the *ORIGINAL* fix was to use that ActiveX download manager from IE10 or earlier, until "they broke that").

    And we *ALL* know that the 4 hour and 51 minute *SECURITY* *CONTEXT* *TIMEOUT* is *ON* *THEIR* *SERVERS*.  Read this thread, and you'll see it's the ONLY! POSSIBLE! CONCLUSION!

    HOWEVER, they *ALSO* said this:

    "Additionally, MSDN Subscription Services are provided “as is,” “with all faults” and “as available.” you bear the risk of using it. We provide no warranties, guarantees or conditions, whether express, implied, statutory, or otherwise, including warranties of merchantability, fitness for a particular purpose and non-infringement. For more information, please read our Microsoft Developer Services Agreement."

    THIS is an ADMISSION that they are *NOT* going to fix it.

    Oh, and there's the obligatory

    "Thank you for your continued support toward Microsoft products and services and have a nice day."

    Microsoft, you OBVIOUSLY! forgot what "Developers, Developers, Developers, Developers" means.

    Wednesday, April 6, 2016 4:49 PM
  • well, after some experimentation, it looks as though they at *LEAST* fixed the 'Range' header problem on the web server!

    This means that, if I can get a 'refreshed' URL every few hours, I can use THAT to continue a download via wget.

    Unfortunately it appears that the timeout on the URL is SHORTER than before, so wget is limited to less than 5 hours of downloading at a time.  [profanity inserted here]

    So here's the new "hack" workaround:

    a) press the 'download' link, while capturing with wireshark.  Cancel it after a few seconds.  some downloading will occur.

    b) find the right stream in the wireshark capture, and grab the URL being opened.

    c) open wget (Linux, BSD, Cygwin, anything 'POSIX') with the following command:

      wget -c -O filename.iso "http://whatever.the.url.is/"   <-- include the GET params

    then, when the download fails after ~5 hours, rinse and repeat with the NEW URL, but the same file name.  the '-c' parameter passes the range header off to Microsoft's server, and you get the next segment of the file.

    This hack seems to work thus far.  But I am still downloading.  I have 1.2Gb to go on a 3G file that stopped at 1.8G

    Thursday, April 7, 2016 12:43 AM
  • I seem to have a workable fix for this issue. I tried it and resumed my downloads the next day and it works!

    Hope it works for the rest of us.

    I use Free Download Manager (http://www.freedownloadmanager.org/) as my primary download manager. You can give it a shot with other tools.

    1. Start downloading as you would usually do.

    2. When the MSDN session expires and your download has stopped in FDM, login again to MSDN and click the download button for the software you wish to download.

    3. For the new download, Free Download Manager shows a popup with the download link... Something like [http://download.msdn.microsoft.com/sg/en_<package name>_x86_x64_dvd_6962141.iso?t=<GUID>&e=1463044868&h=<GUID>]

    4. Copy this link and close/cancel the window.

    5. Go back to the earlier download and open properties (right click -> Download Properties) and paste the newly generated link

    6. Start the download!!!

    This has always worked for me... Hope it works for you guys too


    Thanks Rohit

    Thursday, May 12, 2016 3:30 AM
  • I got a much faster internet connection and I still can't download Visual Studio.   It gets to 30%, a little over 2 gigs, and then it stops and says file size mismatch.   I don't know why they haven't fixed it by now.

    I tried everything. 3 different browsers in every mode possible. The Downloadthemall plugin.

    If Netflix can send out disks for only $8 per month, it seems to me that MS can find a system that helps us get back to work.


    Sunday, May 15, 2016 1:14 AM
  • I got a much faster internet connection and I still can't download Visual Studio.   It gets to 30%, a little over 2 gigs, and then it stops and says file size mismatch.   I don't know why they haven't fixed it by now.

    I tried everything. 3 different browsers in every mode possible. The Downloadthemall plugin.

    If Netflix can send out disks for only $8 per month, it seems to me that MS can find a system that helps us get back to work.


    Please use Internet Download Manager and follow my tutorial on how to resume the download.

    https://social.msdn.microsoft.com/Forums/en-US/1edfbabd-01b2-451c-94d9-465c35060f85/msdn-download-fails-after-3-hours-403-error-cant-resume-windows-10?forum=msdnfeedback#def6d7a2-3e7d-4f5f-b2df-494ea303b3f4

    Checkout my last reply.

    Thanks
    prathaprabhu


    Don't Say Can't Say Can to Not

    Tuesday, May 17, 2016 7:59 PM