Visual Studio 2017 (non-programming) problem
-
A true story from, my university: This happened in the late 60s (or possibly early 70s), long before individual PCs. Even timesharing OSes were not common, except on mainframes. So you had to book hours at the machine - and the book was more or less full 24/7. One student project group was spending Saturday night and Sunday morning in the lab. Then the machine suddenly stopped, refusing to read the program tapes (those were punched paper tape). The lab guy responsible for the machine treated it as his own baby, willing to do anything for it. But... he was also known for rarely being sober on a Saturday night. Sunday morning wasn't the time you'd like to wake him up. But there was a project deadline, and no other alternative. They found a telephone, and called him up. "Hrrmpf!!!" They explained the problem, he grunted "Get me car!" and slammed the phone receiver down. They found someone with a car, drove to pick up the guy, who walked into the lab, blinked a few times, went over to the window, pulled the curtains to shade the windows, and grunted "Drive me home!" Those were all the words he pronounced that morning. No explanation. But the machine was working again. This machine had a paper tape reader running at 3000 char/sec - an amazing speed: 300 in/sec, or 27 km/h. The tape shot several meters out of the reader like a beam. It didn't use mechanical sensors (like most slower paper tape readers), but photocells, which was rather fancy in those days (especially fitting photocells for 8 data tracks + sync track in a 1 inch wide space). When the early morning sun rays made a direct hit on the photocells, they shone through the paper tape, blinding the photocells so the reader wouldn't trigger on the sync track holes: The reader saw just light, believing that there was no tape there, and stalled. Shading the windows brought its vision back again. When I became a student, this machine had earbed "museum" status. But I have touched it, seen it in operation at demonstrations. The morning sun story is well known among computer science students at the university. So based on this story, I believe your claim that the problem depends on whether the fridge door is open or not :-)
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
MS employee here. I unfortunately have no connection to the VS team and am not an avid developer myself, but if you'd like a code for a free support case please let me know, I'd be happy to help get you rolling forward. -- Jon
-
A true story from, my university: This happened in the late 60s (or possibly early 70s), long before individual PCs. Even timesharing OSes were not common, except on mainframes. So you had to book hours at the machine - and the book was more or less full 24/7. One student project group was spending Saturday night and Sunday morning in the lab. Then the machine suddenly stopped, refusing to read the program tapes (those were punched paper tape). The lab guy responsible for the machine treated it as his own baby, willing to do anything for it. But... he was also known for rarely being sober on a Saturday night. Sunday morning wasn't the time you'd like to wake him up. But there was a project deadline, and no other alternative. They found a telephone, and called him up. "Hrrmpf!!!" They explained the problem, he grunted "Get me car!" and slammed the phone receiver down. They found someone with a car, drove to pick up the guy, who walked into the lab, blinked a few times, went over to the window, pulled the curtains to shade the windows, and grunted "Drive me home!" Those were all the words he pronounced that morning. No explanation. But the machine was working again. This machine had a paper tape reader running at 3000 char/sec - an amazing speed: 300 in/sec, or 27 km/h. The tape shot several meters out of the reader like a beam. It didn't use mechanical sensors (like most slower paper tape readers), but photocells, which was rather fancy in those days (especially fitting photocells for 8 data tracks + sync track in a 1 inch wide space). When the early morning sun rays made a direct hit on the photocells, they shone through the paper tape, blinding the photocells so the reader wouldn't trigger on the sync track holes: The reader saw just light, believing that there was no tape there, and stalled. Shading the windows brought its vision back again. When I became a student, this machine had earbed "museum" status. But I have touched it, seen it in operation at demonstrations. The morning sun story is well known among computer science students at the university. So based on this story, I believe your claim that the problem depends on whether the fridge door is open or not :-)
I worked on a similar system in the mid/late 1960s (Leo Computers Society. Leo 3 photos[^]. In Image 1 of LEO III/6 (first computer I worked on) you can clearly see the paper tape reader. I don't know what the actual speed was but like yours "it shot several meters out of the reader like a beam.". As I recall I think the tape we used was 7 hole (6 plus parity), so you could easily tell whether it was in the reader the right way round. Fortunately our computer room was well shaded from the sun so we never had such a problem.
-
A true story from, my university: This happened in the late 60s (or possibly early 70s), long before individual PCs. Even timesharing OSes were not common, except on mainframes. So you had to book hours at the machine - and the book was more or less full 24/7. One student project group was spending Saturday night and Sunday morning in the lab. Then the machine suddenly stopped, refusing to read the program tapes (those were punched paper tape). The lab guy responsible for the machine treated it as his own baby, willing to do anything for it. But... he was also known for rarely being sober on a Saturday night. Sunday morning wasn't the time you'd like to wake him up. But there was a project deadline, and no other alternative. They found a telephone, and called him up. "Hrrmpf!!!" They explained the problem, he grunted "Get me car!" and slammed the phone receiver down. They found someone with a car, drove to pick up the guy, who walked into the lab, blinked a few times, went over to the window, pulled the curtains to shade the windows, and grunted "Drive me home!" Those were all the words he pronounced that morning. No explanation. But the machine was working again. This machine had a paper tape reader running at 3000 char/sec - an amazing speed: 300 in/sec, or 27 km/h. The tape shot several meters out of the reader like a beam. It didn't use mechanical sensors (like most slower paper tape readers), but photocells, which was rather fancy in those days (especially fitting photocells for 8 data tracks + sync track in a 1 inch wide space). When the early morning sun rays made a direct hit on the photocells, they shone through the paper tape, blinding the photocells so the reader wouldn't trigger on the sync track holes: The reader saw just light, believing that there was no tape there, and stalled. Shading the windows brought its vision back again. When I became a student, this machine had earbed "museum" status. But I have touched it, seen it in operation at demonstrations. The morning sun story is well known among computer science students at the university. So based on this story, I believe your claim that the problem depends on whether the fridge door is open or not :-)
That has to be one of the coolest stories I've read. For a minute I thought this was leading into the machine overheating, and he opened the window to allow it to cool down. Overheating was a very common problem, and still is. But the light on the photocells is waaayyy better. :)
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
Maybe you need to try a different IDE.[^] ;)
-
first, make sure you have all updates. second, try staring VS as admin and running the same series of steps. third, check the windows event logs. fourth, turn off any antivirus, etc. and run the series of steps again. fifth, no, this has never happened to me. Google as much as you can, and as a last resort, open a ticket with the beast. wish you the best of luck in this, especially when dealing with the beast (if you have to go that far.). Notes: I have been using VS2017 @ constant professional basis and have not even heard of the issue you are encountering.
Slacker007 wrote:
try staring VS as admin
I've been staring at VS all day, it just stares back at me...
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
I, too, have experienced this behavior from Visual Studio for the last few months, both 2015 and 2017. I have yet to find a solution; however, it seems to help when I take the time to reboot the PC every 10 to 12 debug sessions. The trouble is that I tend to get wrapped up in the task at hand, and forget to do the reboots! I assume that there is something in my PC environment that is causing this, and would love to hear of any solutions anyone out there comes up with.
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
Are you running VS 2017 "run as administrator"?
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
I'm not convinced F5 / Debug always "builds" enough and winds up trying to execute "out of date" code. I'm convinced that a "build" + F5 is sometimes needed versus a straight "F5" at certain times. (My solutions usually involve multiple projects / dll's). And "cleaning" and "unloading / reloading" a project can also "straighten out" VS when it gets symptomatic.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I have had a number of occasions recently when building a project*, that VS stops and kills Windows completely. The mouse cursor disappears, the text caret stops flashing and even Ctrl-Alt-Del does not work. The only way to get out of it is to power off and on again. *I think it only happens when I press F5 to build and debug. And the code itself is not exactly complicated. Anyone else had this?
-
Are you running VS 2017 "run as administrator"?
-
I'm not convinced F5 / Debug always "builds" enough and winds up trying to execute "out of date" code. I'm convinced that a "build" + F5 is sometimes needed versus a straight "F5" at certain times. (My solutions usually involve multiple projects / dll's). And "cleaning" and "unloading / reloading" a project can also "straighten out" VS when it gets symptomatic.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Try Again sorry. I have not tried 2017 yet, I have always had issues with debug mode until I set devenv.exe to launch as admin https://docs.microsoft.com/en-us/visualstudio/ide/user-permissions-and-visual-studio?view=vs-2015 https://docs.microsoft.com/en-us/visualstudio/ide/user-permissions-and-visual-studio?view=vs-2015[^] need coffee..
Toto1107
-
No, just as normal user. I have not actually tried it as administrator, but since the problem is so random it is difficult to reproduce at will.
I recommend you always run VS 2017 "as administrator". You may find some of your occasional issues disappear.
-
Sometimes I build first, and then use F5. At other times I just use F5. In both cases the build either completes (sometimes with errors) or the hang occurs. I have not seen it with a different project, but I am building this one quite frequently.
I'd keep Task Manager open and watch the "profile" of your session and see if there is a pattern for that particular project: all kinds of stuff runs under VS; including JavaScript. Your browsers are also competing for memory: a "window" (process) for each Tab. Each (my) VS session and each browser can easily consume over 1 GB.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal