Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Posts Tagged ‘Networking’

The Case of the Missing Image Preview Tiles

Posted by William Diaz on January 23, 2020

I have been out of it for sometime now, often tied up with one thing or the other and have not been able to contribute recently. But here is a quicky on an often overlooked part of Process Monitor, specifically the basic logging it does for Network Activity.

In this particular case, when using the Insert Online Pictures option available in a new Outlook message, after selecting one of the categories in the initial image window, a series of grayed-out tiles are presented instead of the actual image preview tiles:


I fired up Process Monitor and reproduced the issue, filtering for processes only from Outlook.exe. While quickly scrolling through the events, I noticed a couple entries for Network Activity with an obvious clue as to what was blocking the image previews. I further isolated these events by removing activity for File, Registry, and Process Activity, keeping only Network:


You can see that after hitting the initial IP (52.109…) for what looks to be, a disconnect takes place with path from, which is our firewall returning a false-positive for what it suspects to be adult content. To verify this was the case, I changed  Outlook to use a legacy proxy server (this is done via IE > Internet Options > Connection Settings) that we still keep around and was able to see the image preview tiles after performing the process again. The next course of action would be to modify the company firewall to allow the traffic.


Posted in Office, Troubleshooting Tools | Tagged: , | Leave a Comment »

Configure WinHttp for Proxy

Posted by William Diaz on November 3, 2013

Recently, we were testing a new remote desktop application but I was experiencing problems connecting to the application, and it wasn’t isolated to a single workstation. A few of my other labs were unable to access the application as were other computers as the testing expanded. Admittedly, I should have figured this one out quickly as it was not the first time I encountered an issue trying to access remote desktop applications (i.e. terminal server apps) inside our network. The fact that we were hosting this RDP app internally, though, lead me to dismiss my initial hunch. A quick look with Network Monitor confirmed the problem:


The Windows local security authority processes (lsass.exe) is trying to get out to the cloud to do something, in this case likely some certificate revocation checking (this is usually the case for RDP apps). It keeps on trying by retransmitting until a response is received or it times out, but because we are behind a proxy, lsass.exe will never find a path outside the network. Certificate checking is handled by the Windows crypto API, which relies on WinHttp. Now, by default, Winhttp 5.1 can find a way out of the network if your network is configured to use Web Proxy Autodiscovery (WPAD). We do not, so the fix is to manually configure Winhttp to use some proxy. Since we have this information configured in Internet Explorer (along with proxy exceptions), we just need to import these settings into Winhttp via (elevated command prompt) netsh winhttp import proxy source=ie. Afterwards, the connection problem resolved*.

On the flipside, configuring Winhttp to use a static proxy can also cause connectivity problems for mobile users. I ran into this issue myself today when I was trying to stream a movie from Netflix and kept on encountering the following error: “Whoops. something went wrong… An Internet or home connection network connection problem is preventing playbackError code: H7111-1101”


To verify my suspicion that the opposite was true—that Winhttp was trying to use a proxy it could not reach to do certificate verification checks—I looked in the Windows event CAPI2 logs and could see that the Netflix certificate check was failing:


The details pane further down revealed the cause as the certificate server was “offline”, which is just a generic term for can’t be found. You can verify your winhttp proxy via netsh winhttp show proxy. To correct, simply set the winhttp proxy to use direct connection via netsh winhttp reset proxy when outside the network.

*Certificate verification does not need to be performed for every session, i.e. the initial check is good enough until the crypto API determines that the information is expired and another check needs to be performed.

I am not sure why yet, but Netmon captures on a Windows 8.1 system did not reveal the lsass.exe process. Instead, the process was listed as unavailable.


Posted in Troubleshooting, Troubleshooting Tools | Tagged: , | Leave a Comment »

IE 11, Page can’t be displayed,, & SPDY/3 Protocol

Posted by William Diaz on October 28, 2013

I’ve been taking Internet Explorer 11 for a test drive recently and started to notice an odd occurrence. Upon initially opening IE 11 and typing into the address bar, I am unable to get to the page, instead getting the generic : “This page can’t be displayed…


A quick refresh, however, had no problems taking me to the page afterwards. Closing IE (and making sure all iexplore.exe processes are closed via the Task Manager) and typing the same URL again would reproduce the problem roughly 8 out of 10 times. A quick look with Network Monitor should that connection was, in fact, successful:


Looking at one of the frames in the network capture showed the presence of an additional HTTP protocol I wasn’t familiar with in Internet Explorer, SPDY/3:


I remember seeing it in the Advanced tab of the Internet Explorer settings:


Unchecking this setting resolved the issue. I am not sure why this is happening. SPDY/3 is a relatively new open protocol introduced by Google and being adapted by IE. More about it can be read here: & In short, it makes the browser speedier by reducing web page load times.


Seems to be reproducible only behind a proxy, TMG in our case.

Posted in Uncategorized | Tagged: , | 11 Comments »

Java 7 Domain Account Locks

Posted by William Diaz on August 16, 2013

We recently moved from Java 6 to Java 7, specifically JRE 7 Update 25. Immediately, we began get reports of user accounts getting locked after the affected users visited web sites hosting Java applets. For the most parts, the applets would run until the 5th attempt to load-refresh the applet and then the domain account would get locked. The initial look with Network Monitor showed that authenticated users were failing at the proxy level:


The spot-workaround was to create bypass rules for the individual sites to allow all users to pass without authentication, which was by no means a elegant since it was a reactionary approach  that waited for user’s to get locked across various offices and then report the problem to tier 1 and then escalate.

When the support issues began to settle down, I began to look more deeply into the problem. We took a non-production proxy and removed all the rules that were created over the previous days so that any Java applet would begin failing authentication (I used the Java Verify page as my test). I have to admit, network traffic and protocols are not my Zen, but as I began to look at various captures and figure may way around netmon, I saw the same theme each time, Kerberos authentication failing:

Read the rest of this entry »

Posted in Troubleshooting | Tagged: , | 1 Comment »

A Little Netmon Goes a Long Way

Posted by William Diaz on August 13, 2013

You don’t necessarily need to be a network guru to use Microsoft Network Monitor. I have used it more than a few times to troubleshoot client side applications that fail to connect to external resources for whatever reason. For example, a user unable to logon to a some external server, receiving the follow error: “The remote server returned an error: (502) Bade Gateway

7-25-2013 6-16-51 PM

I tried the site myself with Netmon capturing a trace and saw the remote server was trying to establish a secure connection through a port other than common 443:


And here where printing from a remote app was failing to pass through our TMG proxy:


Read the rest of this entry »

Posted in Troubleshooting Tools | Tagged: | Leave a Comment »

You Might Have Resolved that Networking Issue Because You Unknowingly Broke Your Firewall (but also isolated the cause)

Posted by William Diaz on May 10, 2012

A lot of vague networking issues on user workstations are sometimes troubleshot by running the netsh winsock reset catalog command, often without knowing what it does. When you run this command, you are resetting the layered service providers that come with Windows and removing all others that did not come with Windows. These “others” might be MS firewall clients, security proxies or 3rd party wireless communication apps that come with “Air Cards” used by mobile users.

In the environment that I work in, our workstations have the Microsoft Firewall Client or TMG client installed. You can directly see this as a layered service provider by opening msinfo32 and going to Components > Network > Protocol:
If you run netsh winsock reset you end up removing any LSPs that are not part of the Windows-Out-Of-The-Box installation. If your LSP application is self-aware, like in the case of the MS FWC or TMG client, you might notice a warning of some type:

This is a sign you need to run a repair or reinstall your LSP application (in this case, a repair of the FWC\TMG client is enough to fix and put the LSPs back in place).

The irony is that, if running netsh winsock reset resolved whatever mysterious networking issue you encountered, then you might have isolated the cause of the issue to a problem with the LSP application. I encountered this myself way back in my first blog post of the The Case of the Random Internet Explorer Crashes.

Posted in Troubleshooting | Tagged: | 2 Comments »

The Case of the Locked Domain Account

Posted by William Diaz on November 1, 2011

Account locks normally are not a big deal to troubleshoot. Often times it is a user typing in an incorrect password to the account they are trying to logon to too many times. Other times, it is being caused by expired or incorrect cached credentials being used to authenticate to some network resource. In the latter case, this is a simple matter of going onto the workstation that has been identified as one locking the account and removing the cached credentials.

In Windows XP, this can be done by going to Start > Settings > Control Panel > User Accounts > Advanced (or Manage Passwords for non-admins) > Advanced > Manage Passwords. Alternatively, you can just use the control userpasswords2 command.
Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , | Leave a Comment »

The Woes of Cloud-Based Web Security

Posted by William Diaz on October 14, 2011

Our Production ISAs’ have an added cloud-based layer of security to protect our network from malicious web content. Every now and then, though, we run into false-positives. Some of these are:

Intentionally Corrupts Downloads

The Case Of The Corrupt Download & The Case of the Zip File That Wouldn’t Open

Stops web pages from loading by preventing the execution of legitimate scripts: Read the rest of this entry »

Posted in Troubleshooting | Tagged: , , | Leave a Comment »

The Case Of The Corrupt Download

Posted by William Diaz on August 23, 2011

The following error was being reported while internal users were trying to install the latest Flash Player from Adobe: “Internal error… ABORT: Certificate authentication failed, please re-install to correct the problem. (/0)
8-23-2011 11-48-33 AM
Read the rest of this entry »

Posted in Troubleshooting | Tagged: , | 5 Comments »

Socket To Me (The Case of the Failed Stock Trading Program)

Posted by William Diaz on July 1, 2011

This case demonstrates the importance of understanding basic networking components in Windows and how they work in an environment that sits behind a proxy. The methods used to uncover the culprit did not involve a detailed analysis of network traffic or using any utilities or tools that do not already come with Windows. In fact, because this was time sensitive and I was not afforded the luxury of troubleshooting afterhours, I could not rely on any of the various tools I turn to, like Process Monitor, crash dumps, or Network Monitor. Previous troubleshooting steps taken before it got me involved timely uninstall and reinstall of the Java client, an IE Reset, and upgrading from IE 7 to IE 8, all to no avail and creating irate user syndrome.

To start my analysis, I used Process Explorer to easily see which processes were involved in starting the problem application (Task Manager makes it difficult to quickly see which processes are starting and stopping). An Internet Explorer shortcut to a login page actually initiates the launching of the stock trading application, and, after logging in, two processes are spawned, javaws.exe and javaw.exe:

Read the rest of this entry »

Posted in Troubleshooting | Tagged: | Leave a Comment »