VS2010 slowed to crawl when Hurricane Sandy killed internet connection - visual-studio-2010

I'm in the greater New York area, and hurricane sandy has left us with power, but has killed our Internet connection. (I'm typing this on my ipad at a local McDonalds)
This has dramatically slowed VS2010 when starting a debug session within the IDE. There now seems to be a long pause...ten seconds for each dll...for every dll referenced in the project. Now it takes several minutes every time we run our project.
The project itself has absolutely no Internet functionality...seems to be strictly related to VS 2010.
Disabling MS Symbol Server had no effect, and I could not find anything else in VS settings that would need the Internet.
Edit
We now have internet again, and startup times are back to around 20 seconds.
Previously, I also tried disabling Symbol Server again, and this time it did have a major effect - reduced startup time from 4 minutes to 1 minute. Don't know why I did not see the same result the first time I tried.
Some testing with Win7 Resource Monitor indicates that VS is trying to talk to 224.0.0.251 and 252...Multicast DNS address and Link-local Multicast Name Resolution address respectively).
Also 239.255.255.250 (Simple Service Discovery Protocol). Got the definitions by looking up the IP addresses on Wikipedia, but that does not really help me.
Any suggestions on how to track this down?

Related

Could not recover SATA HDD after 5 attempts Mac

The Mac has decided to freeze and restart several times a day while I'm using it.
panic (cpu 2 caller 0xffffff801a579938): watchdog timeout: no checkins from watchdogd in 93 seconds .....
Used the repair disk utility tool multiple times in different recovery modes.
I Used every free admin fixing tool, clean up tool and error reporting tool on the app store.
Launched my Mac in all sorts of different recovery modes. I literally pressed and used every restart keyboard combination you can with a Mac. And I used them several times over and over in different scenarios.
Spent hours researching every forum and reading every article of similar problems and solutions.
Download the manual updates and installed them each separately
After a day of frustration i found then solution
The fans internal sensor wasn’t working any more.
I set the automatic controls using Macs Fan Control app and in Custom switched to Sensor-based value and selected CPU PECI from drop down and set 30 in Temperature that the fan speed will start to increase from and 90 in Max temperature. Fans now kicking in and cooling down the processors and preventing from re-starting.
Source

Access slow launch from .accdb, but not from within Access application

This just started happening for no good reason I can find.
If I launch the MSACCESS.EXE program, then open a database. The database opens within 1 second.
If I launch the same database by double-clicking on the .accdb file's icon. It takes about 40 seconds for the Access window to appear, and less than 1 second after that the database opens.
The database is local, and both Access and the DB are on an SSD. The system is an Asus Z97 motherboard, i7-4790K # 4MHz (not overclocked) with 32gb RAM and about 200gb of free hard disk space.
In both cases, performance after opening is excellent with no issues. It appears it's only the launching of MSACCESS.EXE by double-clicking a .accdb file that is affected. I double-checked the file association for .accdb and it points to the correct executable.
I captured some data with Performance Monitor during the 40-second pause. MSACCESS.EXE is using about 0.4% CPU, doing almost no disk I/O, and there's no network activity.
I've already tried "Compact and Repair" but that had no effect.
This just started happening, and now seems to be affecting Access on ALL .accdb files. They open instantly from within Access but take 40 seconds to open when double-clicked. I haven't installed any new software or Windows updates recently.
Curiously, if I change the .accdb extension to .accdr (runs the db in the client runtime instead of full Access) the database will launch instantly.
What could possibly be going on here? I've searched the web and found some posts having to do with databases on a network share, but that doesn't apply here.
For anyone else encountering this issue, it appears this bug has nothing to do with Access specifically.
I needed to shutdown the machine, and when I did so, Windows seemed to completely ignore multiple shutdown requests. As I was googling to troubleshoot, after about 10 minutes, the shutdown did finally start. It took another 10 minutes to shutdown.
After rebooting the slow launch problem no longer occurs, there's only about a 2 second delay, which I assume is just MSACCESS.EXE loading "cold".
So, the problem is most likely in Windows and not Access.
I spent ages looking for the answers to this on various sites but eventually cobbled together my own fix, so hopefully this saves others some time.
This worked for me and reduced the load time from circa 4 minutes - even just opening a blank accdb fle - to seconds... So 4 mins if double-clicking an accdb. Once MS Access open and using File | Open it was fast.
I had two instances of MS Access both on Windows Servers that can see the Internet but goes through a corporate proxy etc.
After getting some hints by Googling this issue I suspected that the 4 mins or so was some sort of timeout trying to access a site or sites (MS Office apps do this) and that eventually when the proxy returned a timeout then Access started responding again. It was quick on the 2nd open because it didn't redo this request.
Based on this, I tried to divert certain sites to 127.0.0.1 and turn off all the Internet options in Trust Centre | Privacy etc. Nothing worked.
Finally, I got the solution. In Windows Defender firewall I created a new Application rule for the MSACCESS.EXE. This was an outbound rule that blocked all Internet traffic. After this the first double-click was fast again. I assume with traffic totally blocked, whatever request is going out to sites, is immediately stopped and returns a "no internet" to Access, which then carries out executing, rather than waiting for the 3-4min timeout.

Mainframe problems, due to internet drops

Apologies at forehand, for the amound of information, but I tried to be as thorough as possible. If any information is still needed, please let me know.
Background:
I am a junior mainframe programmer, who started out a few months ago with learning the mainframe. I know my way around pretty well, when it comes to jcl, cobol etc, but when it comes to maintenance of the mainframe, I'm not all that familiar.
I'm currently following a course, using the mainframe of the institution (which is an emualtor, not a real one). Sadly my teacher is still learning how to maintaine a mainframe, so he doesn't really know either. So calling the tech department is not an option.
Basically I am hoping that someone here, heared of the problem before. I don't know where to look. If the problem is in my wifi connection, or if it is with the mainframe. Seems to go both ways.
Specifications:
My OS: Windows 7
Laptop: HP Elitebook, with dualboot Windows7 and Linux
Mainframe emulator: Tom Brennan's Vista TN3270, Z/OS
Just in case I added my Vista.ini below
Connection: through external ip adres
N.B. I have reinstalled wifi drivers, this didn't do anything.
Problem:
The mainframe workt properly up until 2 weeks ago, when my provider performed some maintenance on the internet in my neighbourhood. Since then, I am experiencing internet drops. They happen every +- 5sec and last (as far as I can tell) around 20-30 ms (both on wifi and cable).
It is not long enough for the browser and other applications to notice. Even my windows doesn't notice the drop. My mainframe connection however does notice the drop. My connection with the mainframe is not lost completely. The screen stays open and visible, but pressing any button does nothing. I then have to close vista, reopen, loggin again and then it works fine. Till 5 minutes later, when it starts over again.
Last night I pinged the IP and at the same time, pinged google, in order to figure out if it whas only the mainframe connection with a problem, or not. The ping did fine for minutes on end, until I started Vista after a few minutes and then both pings crashed instantly, couldn't send or receive any packages anymore.
Extra info:
I called my provider and they send a tech guy, they say there is nothing wrong with my internet connection.
Connecting to the external IP adres, from another wifi connection gives me no problems. It only goes wrong from my home addres / wifi.
Other people on the same mainframe have no problems, no mather where they are.
There is another mainframe I can reach and that one does not seem to have any problems what so ever.
Other ssh / external connections to other IP adresses don't give me any problems.
I tried testing it on Linux and other computers, but without having Vista to try, i don't now how else to test the problem. Since browser and other applications have no problems.
I get no message what so ever when the mainframe connections stops.
I looked at a number of logfiles on the mainframe, but basically I don't know which ones I need to find a possible clue or answer.
If someone knows anything, even just to send me in the right direction, it would be very much appreciated. Having to reconnect every 5 minutes is starting to be really annoying and keeps me from my studies/work.
[Vista]
LastSession=standard.ses
Hostnames=
IPnames=
Portnums=3270,23
TN3270E=1,1
SSL=0,0
Lunames=,
KeepAliveTime=60

odoo 9 performance on ChromeOS

We are noticing a strong downfall in ODOO performance of the users that use ChromeOS, either using ChromeBook or ChromeBoxes (with different configurations...also very fast ones). After the startup of the machine all seems fine but after a while (depending on your activity) we notice a strong downfall in Performance. It is like the machine is not responding at all and after a few seconds (sometimes up to 30 seconds) it continues with opening the screen and seems to be very quick again. Restarting the browser and clearing the cache gives some relieve but the issue keeps coming back. Strange thing is that on our older windows machines (running Chrome Browser) we do not see this issue.

Visual studio Ultimate 2013 slow start on debug

I have installed visual studio 2013 Ultimate on Windows 8 enterprise edition.
When I start debugging an mvc project (which pretty empty) : it takes 27 seconds to start the debugging. I assume it's because IIS express 8 is loading symbols and hangs somewhere.
I have tried an empty mvc project and it starts in 10 seconds : which is very unacceptable.
I have tried :
- deleting all breakpoints
- enabling just my code
- unchecking symbols downloading from microsoft servers and downloading them on a local folder on the computer
- disabling intellitrace (was already disabled when i went to see)
- disabling just-in-time (was already disabled when i went to see)
- unplugging the ethernet cable (yes, i am pretty desperate)
- no antivirus is turned on
The first request (when i launch debugging) always take 27 seconds according to glimpse. The controller run under 1 second which is "acceptable". All the next requests are fine.
But I can't work with the 27 seconds each time I launch debugging.
Can someone help me ? I do not know what to do next.
My computer is a dual core 3Ghz with 4 Go of Ram and a 7200 rpm hd. I don't think it's hardware related.
Thank you very much.
UPDATE :
As soon as I start to use NLog in the code, it takes 30 sec to launch the debug mode.
If I comment all the place where I log something, It takes 10 sec. Sometimes less.
How much time you guys take to launch the debug mode ?
It's quit possible you are referencing dead or slow symbol path. For example, you're at home but accessing a symbol path on company's server. Check it under Tools -> Options -> Debug -> Symbol. If it's ok, check your system as follows.
Make sure there is no other process that runs out of your hardware resources.
First check if CPU usage is too high after staring debugging. If CPU usage is too high, use Process Explorer to check what activities VS Is performing. If they are in an extension thread, disable that extension. If they are in VS own thread, it's most likely a VS bug you can report to MS.
Check if memory usage is too high. If VS memory usage is too high, given that you just start simple debugging, it's a VS bug.
If both CPU and memory are ok, it's probably related to IO operation. Use Process Monitor to check which files are being accessed, especially files on remote machine.
This is how I troubleshoot the same problem on my machine. Hope it help you.

Resources