Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Posts Tagged ‘Internet Explorer’

The Case of the Phantom Proxy Settings

Posted by William Diaz on December 3, 2015


Not too long ago we began to notice that users who were opening IE after logging onto some workstations or Citrix servers they did not have a previously existing profile on were getting proxy settings applied in IE that were not being defined in any group policy object. Our local office proxies are applied later in the GPO processing so if it was anything coming before that, it should have been overridden by local GPO. The quick remedy was simply wait for policy to apply in the background or manually run gpupdate. But we still needed to address the cause as in some cases the proxy server was no longer reachable, preventing users from getting out to the Internet.

To get an idea of what might be happening, we deleted a profile from a machine and logged onto it. We then fired up Process Monitor and left it running while launching Internet Explorer for the first time. After verifying that incorrect proxy setting was getting applied, we stopped the trace and the log was sent my way. Proxy settings are applied in the registry so I knew I would be looking only at registry events, searching for the string of proxy server name in the log, and specifically looking at the operation for RegSetValue. From here, it was a simple matter of opening the Properties for that Event and going to the Stack tab.

clip_image001

The component setting the phantom proxy server (iedkcs.dll) was coming from the Internet Explorer Admin Kit or IEAK. This is otherwise known as Active Setup and its what IE will use when it is initially launched by a new user logon if the IE install was configured using IEAK. Also known as Branding, Active Setup for IE looks for INSTALL.INS if it defined in the registry. You can find this file in Program Files (x86)\Internet Explorer\CUSTOM. Looking in the INSTALL.INS, I could see under [ConnectionSettings] the phantom proxy server. You can read about the internals of this here: https://support.microsoft.com/en-us/kb/2029043

At first this was a bit baffling because I had setup the rollout for IE11 using the standalone IE11 MSU and required dependencies and not the IEAK. However, after glancing at the INSTALL.INS file again, I noticed this was actually coming from an earlier IE 9 deployment, which was created using IEAK by my IE predecessor:

image

To correct, I referred back to https://support.microsoft.com/en-us/kb/2029043 and concluded that this could be avoided by going to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\>{2A2F9EE5-7FE3-44E8-AD75-72B5704DBCB4}] and deleting "StubPath"="RunDLL32 IEDKCS32.DLL,BrandIE4 CUSTOM".

To correct on new workstations going forward, I simply created a REG DELETE command in the Task Sequence after the IE11 setup to remove the value. For existing machines, a GPP registry is the easiest way to go.

Advertisements

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

Another Case of IE and Outlook Crashes

Posted by William Diaz on February 26, 2015


I haven’t done one of these in quite awhile. So without further ado.

The symptom: Internet Explorer 11 and Outlook were crashing*. This was happening in all cases after applying a new task sequence. The event viewer did not produce any events that would help so I configured the system to capture crash dumps for applications. After rebooting, I reproduced the crash by simply opening IE an grabbed one of the dumps and ran it through an x86 debugger (by default, the 32bit Content tabs in IE 11 run as 32bit processes). Using ! analyze –v command produced the following output:

STACK_TEXT: 
WARNING: Frame IP not in any known module. Following frames may be wrong.
0339e974 6818a97d 005a09f8 0339e994 5226b9f5 0x490054
0339e9d8 68193c6f 0059f730 0059f7ec 5226bb49 D3D10Level9!UMAdapter::UnderlyingGetCaps+0x31
0339eb64 681940c2 0059f730 0339ebb4 00000002 D3D10Level9!UMAdapter::Open+0x165
0339eb98 69e0cae6 0339ebb4 523e5d23 00020009 D3D10Level9!OpenAdapter10_2+0x45
0339ebdc 69de09c2 005a09f8 0059f35c 69dda858 d3d11!NDXGI::CUMDAdapter::CUMDAdapter+0x18b
0339edc8 69de05fd 0339f0f0 00000002 00000029 d3d11!CCreateDeviceCache::CUMDAdapterCache::Load+0x1fc
0339ee18 69de12f3 0339f0b8 0339ee90 00009300 d3d11!CCreateDeviceCache::CAdapterCache::ResolveUMDAndVersion+0xc8
0339f1f4 69de1e4e 00000000 00595190 00000000 d3d11!D3D11CoreCreateDevice+0x353
0339f484 69de1bdd 00595190 00000000 00000000 d3d11!D3D11CreateDeviceAndSwapChain+0x268
0339f4bc 5bd5b4ed 00595190 00000000 00000000 d3d11!D3D11CreateDevice+0x2c
0339f4f8 5bd5c698 00000001 0339f58c 0339f564 mshtml!CDXGIHelper::CreateD3DDevice+0x48
0339f520 5bd5bc31 72657200 001af5f2 005910fc mshtml!CDXHelper::CreateD3D11Device+0x99
0339f6fc 5bd5ba45 00000000 00000000 00000000 mshtml!CDXResourceDomain::EnsureD3DDevice+0x82
0339f718 5bd5b9ad 00000000 00000000 00000000 mshtml!CDXResourceDomain::Initialize+0x67
0339f734 5bb35771 5c81e03c 00000000 00000000 mshtml!CDXResourceDomain::Create+0x48
0339f76c 5bd5a4c9 0339f78c 00000000 00538c78 mshtml!CDXResourceDomain::EnsureSharedDomain+0xa9
0339f7a0 671015ca 670b21cc 00000000 00000000 mshtml!CDXResourceDomain::EarlyStartDisplaySystem+0xe8
0339f7a4 670b21cc 00000000 00000000 00545cf8 ieframe!DirectUI::TouchEdit2::_UpdatePrompt+0x22
0339f7bc 77647df9 00538c78 744d2d1c 0053b958 ieframe!ExecuteWorkItemThreadProc+0x30
0339f830 77632b65 00538c78 00545cf8 744d2cbc ntdll!RtlpTpWorkCallback+0x11d
0339f990 76d6339a 0053b950 0339f9dc 7761bf32 ntdll!TppWorkerThread+0x572
0339f99c 7761bf32 0053b950 744d2cf0 00000000 kernel32!BaseThreadInitThunk+0xe
0339f9dc 7761bf05 776325c1 0053b950 ffffffff ntdll!__RtlUserThreadStart+0x70
0339f9f4 00000000 776325c1 0053b950 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  ~2s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  unknown!printable+0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: unknown

IMAGE_NAME:  unknown

DEBUG_FLR_IMAGE_TIMESTAMP:  0

 

I know D3D is Microsoft Direct X. To validate this, simply run the command lmvm d3d11:

0:002> lmvm d3d11
start    end        module name
69dd0000 69f45000   d3d11      (pdb symbols)          c:\symbols\d3d11.pdb\A40CED7361AB405886384123277BE23F1\d3d11.pdb
    Loaded symbol image file: d3d11.dll
    Image path: C:\Windows\System32\d3d11.dll
    Image name: d3d11.dll
    Timestamp:        Wed Mar 27 18:48:45 2013 (5153774D)
    CheckSum:         0017E157
    ImageSize:        00175000
    File version:     6.2.9200.16570
    Product version:  6.2.9200.16570
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     D3D11.dll
    OriginalFilename: D3D11.dll
    ProductVersion:   6.2.9200.16570
    FileVersion:      6.2.9200.16570 (win8_gdr.130327-1526)
    FileDescription:  Direct3D 11 Runtime
    LegalCopyright:   © Microsoft Corporation. All rights reserved.

 

A good guess is that the issue we are encountering is graphics driver related.

I wanted to see if that was the case with Outlook as well. However, that would require a different approach as Outlook was not producing any crash dumps to run through the debugger. Although there are several ways to work around this, the simplest and most GUI friendly is to use DebugDiag from Microsoft. I wrote about this sometime ago and it has since moved to version 2.1 but the approach I still the same for the most part. I simply ran DebugDiag Collection, created a crash rule, specified outlook.exe as the process. After starting Outlook, several dumps were generated. When complete I then launched DebugDiag Analysis, selected the last dump and then selected Start Analysis. The report generates as an htlm file and opens automatically in IE.

The analysis takes some of the guess work of how to proceed when you have little or no understanding of WinDbg. I could see my suspicion that the issue common to both IE and Outlook was the same, which does not surprise me as they both share common modules.

image

As a proof of concept, one way to test issues you suspect may be graphics related to IE if your system uses dedicated graphics is to disable GPU rendering in IE. This is done by going into the Control Panel > Internet Options > Advanced > and checking Use software rendering instead of GPU rendering (note, although the asterisk indicates you should restart your computer, only restarting IE may be required). In my case, this corrected the problem with IE so I was sure now that the issue was related to the graphics card. Before updating the driver, I checked the display information to see if perhaps the drivers were missed and maybe generic drivers were installed. This didn’t seem to be the case:

image

I would still update the drivers anyway. After doing so, both Internet Explorer and Outlook opened without crashing. Interestingly, after updating the drivers, the workstation reported a different video adapter model:

image

In the end, the resolution was to install the correct graphics drivers during the task sequence.

Note, in some cases the crashing application may report via WER (windows error report) popup. If you examine the details, you may note that the fault module name contains a stackhash code a7aa, which is often a indicator that the issue is likely related to a driver issue for the video subsystem:

SNAGHTML31458dc0


*Oddly enough, I could not reproduce the issue when connected remotely using RDP. This should have been a clear indicator as to what the issue really was because RDP does not use the host system’s graphics drivers but those of the connecting system instead. 

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

Why is the IE 11 MSI Generated from the IEAK Failing?

Posted by William Diaz on December 8, 2014


There has been some chatter about the Internet Explorer 11 MSI that is generated from the IEAK failing while the EXE is able to run successfully. I ran into this myself last week while trying to manually execute the package. The IE11_main.log always showed the same error: “ERROR:   Error downloading prerequisite file (KB2834140): 0x800c0005 (2148270085)

image

After a day or so of troubleshooting I realized the problem. When the IE11 setup runs, it needs to go out to the Internet to check Microsoft for prerequisite updates; both the MSI and the EXE do this. But the MSI (msisexec.exe) executes in the context of the local system account. By default, the local system account tries to find a direct path to the Internet, but if you are behind a proxy this is going to fail as the MSI child processes (specifically ienrcore.exe) are bypassing the proxy.

image
The EXE on the other hand when run manually executes in the context of a user account with Internet Access. That does not mean you are entirely out of the woods with the EXE package. If you are automatically deploying and leveraging SCCM the EXE (like the MSI) is still going to executed by the local system account. To overcome this, you need to configure the local system account to use a proxy (or not use a proxy, or update your proxy). This can be done via BITSAdmin with the following command:

bitsadmin /util /setieproxy localsystem MANUAL_PROXY MyProxy:8080 "<local>"

Another workaround is to simply install the prerequisites before installing IE 11. The required KBs are:

  • KB2670838
  • KB2786081
  • KB2834140
  • KB2882822
  • KB2888049

Last, you should also be able to extract the cab files from these KBs and add them via IEAK custom components step in the IEAK. I have yet to get this to work, however, as the package still wants to go out to the Windows Update site. If you have gotten this to work, let me know how you did it.


UPDATE

I have decided to use the IE11 redistributable and avoid IEAK. Injecting updates into the package via IEAK is too much work. Fortunately for us we control everything we need to via group policy so there is no need for customizations. A script to install the prerequisite updates and then IE11 is much simpler.

Note, if you install updates then install IE11 in the same script, the IE11 installer is still going to want to go out to the Internet to check updates if you just run the executable command. There are two ways to workaround this. One is to install the updates, restart, then install IE11. But this means you have to break up your deployment into two steps. Fortunately, you can work around this. The answer lies in the IE11_main.log using DISM. When a successful install (with Internet Connection) of IE11 is completed you can find the command in the log:

image

Just extract the redistributable and then install IE11 via the main CAB using DISM and then the two MSUs using WUSA. For example:

::Create temp directory if not present to extract IE11 
MKDIR "C:\temp\IE11"
ECHO Installing prerequisite updates for Internet Explorer 11
"%~dp0Windows6.1-KB2670838-x64.msu" /quiet /norestart
"%~dp0Windows6.1-KB2786081-x64.msu" /quiet /norestart
"%~dp0Windows6.1-KB2834140-v2-x64.msu" /quiet /norestart
"%~dp0Windows6.1-KB2882822-x64.msu" /quiet /norestart
"%~dp0Windows6.1-KB2888049-x64.msu" /quiet /norestart
ECHO Installing Internet Explorer 11. Please wait…
::A reboot is required here, otherwise the IE11 Installer wants to still go out to Internet to check updates
::We can avoid this by using DISM instead to install IE11
"%~dp0IE11-Windows6.1-x64-en-us.exe" /X:%systemdrive%\temp\IE11
%systemroot%\system32\dism.exe /Online /Add-Package /PackagePath:%systemdrive%\temp\IE-Win7.CAB /quiet /norestart
%systemroot%\system32\wusa.exe "%systemdrive%\temp\IE11\IE-Spelling-en.MSU" /quiet /norestart
%systemroot%\system32\wusa.exe "%systemdrive%\temp\IE11\IE-Hyphenation-en.MSU" /quiet /norestart
::Cleanup 
RMDIR C:\temp\IE11 /s /q

 

Note: if you are going to be using 32bit Configuration Manager client to execute the batch file above in 64bit Windows, you will need to replace system32 paths to sysnative.

Posted in Uncategorized | Tagged: | 6 Comments »

More Web Page Troubleshooting with IE Developer Tools

Posted by William Diaz on February 11, 2014


A user was complaining that they could not access a web page. The initial impression was that it was being blocked. I bypassed the proxy mechanism in place that normally restricts web traffic but saw that the page still could not be loaded. The message alluded to something locally installed that may be the culprit, but this was really just a generic “catch-all” error message: “Is feedly blocked? Feedly is not able to load. It is probably because one of your extensions is blocking it…

image

I decided to load up the Developer Tools in IE to see if it was problem with the script in the web page. To do this, just press F12 or go to Tools > F12 Developer Tools. Afterwards, select the Script tab and select the option to Start debugging. I selected the hyperlink in the right portion of the debug window and it took the cursor to the problem part of the javascript code.

image

Don’t worry, you don’t necessarily need to be a program-code debugger to figure this out. That what the Internet and your favorite search engine is for. Searching the debug error Expected identifier, string or number IE9 turned up two top hits that pointed out that a trailing comma after an object or array is a bad idea and that IE9 specifically cannot handle this problem script.

The workaround is to use an alternative browser like FireFox or Chrome (they are not as restrictive with malformed javascript). Internet Explorer 10 or 11 also seems to be handle this problem more gracefully, too, and allowed the page to load normally.

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

The Case of the Ghost Files in IE

Posted by William Diaz on January 24, 2014


While in the process of composing an web-based email today via Internet Explorer, I noticed something odd when I went to attach a file to the message. In the IE file upload dialog there were a series of files listed on the desktop that I knew were not really there. Judging by the dates they had been hanging around for some time now but I had never noticed them (and, no, they were not hidden or marked as protected operating system files):

SNAGHTML1303b167

The files themselves were no mystery; they are nothing more than text files that dump process, thread, and stack information to the desktop when the JRE crashes. I tried to attach one of these to the web message but nothing would happen. However, from within in the dialog box I could right click and open them like any other files. Attempting to move the file also failed because the file itself apparently didn’t exist:

SNAGHTML1319e5a1

If that was the case, I should then get the same message trying to copy it back to the desktop. Instead, the dialog this time indicated it did exist:

SNAGHTML131cc2f5

I wondered if I could access these ghost files from outside IE by, for example, attaching them to a message in Outlook. Not surprisingly, the same set of files did not appear from the desktop location:

SNAGHTML132052f4

This was likely something specific to IE. To determine where the files were actually residing, I turned to Process Monitor, started a trace for file activity and proceeded to open one of the ghost files via the IE File upload dialog box. Afterwards, I stopped the trace and did a search for the file in question.

image

There was half the mystery, the files actually resided in C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\C\Users\username\Desktop. The other half of the mystery was then just a matter of some quick research into IE and Virtualized folders. That lead me to this MSDN article Understanding and Working in Protected Mode Internet Explorer. In short:

A Compatibility Layer handles the needs of many existing extensions. It intercepts attempts to write to medium integrity resources, such as the Documents folder in the user profile and the HKEY_CURRENT_USER registry hive. However it will not intercept writes to system locations like Program Files and HKEY_LOCAL_MACHINE. The compatibility layer uses a Windows Compatibility Shim to automatically redirect these operations to the following low integrity locations:

  • Documents and Settings\%userprofile%\LocalSettings\TemporaryInternet Files\Virtualized (pre-Vista)

If I unchecked Enable Protected Mode in IE the virtual files no longer appeared in the file IE file dialog. Not that you don’t want to do that, just delete the files instead.

Posted in Troubleshooting | 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:

  image

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”

Capture

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:

Capture2

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.

image

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

IE 11, Page can’t be displayed, Google.com, & 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 www.google.com into the address bar, I am unable to get to the page, instead getting the generic : “This page can’t be displayed…

image

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:

image

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:

image

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

image

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: http://en.wikipedia.org/wiki/SPDY & http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3. In short, it makes the browser speedier by reducing web page load times.


Update

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

Posted in Uncategorized | Tagged: , | 11 Comments »

The Case of Google Earth Interrupting Internet Connectivity

Posted by William Diaz on September 11, 2013


So today I received another complaint of Google Earth causing Internet Connectivity problems. In the past, I had ignored these because I was never able to recreate the issue as I did not have enough information on the method being used to cause it. This time I was a little bit more determined so I had one of the helpdesk techs show me first hand what was happening and armed with that I went off to install Google Earth on a lab and attempt to recreate. The steps to recreate are rather straight forward, just do a few searches and lots of zooming or scrolling in Google Earth until. At some point, the telltale sign that Internet connectivity had been lost would be indicated when when the Tour Guide pane became blank:

image

When operating normally, the Tour Guide pane displays images relevant to the place you are searching or viewing. At this point, any browser would also fail to connect to any external resource, e.g. the Internet, returning a page not found or other connectivity failure message. After what seemed like a couple minutes, connectivity would then be restored.

Some troubleshooting was already attempted earlier by pointing the browser to an unmanaged (free-for-all) proxy, which avoided the problem. My guess at that point was that our TMG was somehow cutting the connection for the workstation for some amount of time. Why? I also assumed that Google Earth is simple saturating the TMG with too many requests. Think about it, every search, zoom, scroll, and pan is basically a file-image request. Keep on doing that in a short period and you are likely to trigger some hardware or software appliance that a DoS attack is taking place. To backup my hypothesis, I turned to my latest and favorite tool, Network Monitor. I started a trace, reproduced the issue, and stopped the trace. The capture was fairly large so I needed to set a filter. Some quick searching through the standard filters revealed a filter for Http error (Load Filters > HTTP > http Error). After applying the filter, I could see the issue:

image

502 Bad gateway – Proxy Error (The number of HTTP requests per minute exceeded the configured limit). Some quick research pointed to this Forefront TMG article Overview of flood mitigation. In short, TMG rules may have to be modified or created to bypass flood mitigation for Google Earth. Currently, these are the two servers Google recommends for bypass:

  • maps.google.com
  • geoauth.google.com

This is also known to be an issue for home and small offices that are not behind a proxy. In those cases, it is likely the router’s firewall-DoS configuration that is the culprit.

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

Troubleshooting Web Certificate Issues in IE

Posted by William Diaz on September 4, 2013


A while back ago one of our internal servers presented an issue to us. While trying to navigate to it, we were running into the following warning: “There is a problem with this website’s security certificate…”

image

The real problem was that clicking the Continue to this website (not recommended) link didn’t let you proceed to the login page, it would simply refresh this page each time. To explorer causes with certificate issues in Windows you simply need to enable CAPI2 logging. CAPI is Microsoft’s cryptography API. Logging can be enabled by going into the Windows event viewer > selecting Application and Services Logs > Microsoft > Windows > CAPI2:

image

Right-click the Operational log and select Enable Log. Recreate the issue, right-click the log again, select Disable Log, and look at the individual events, especially those error events. You will need to scan through the Details tab to isolate the issue as no general information is provided. This is not as bad as it looks. You don’t necessarily need to understand everything you are looking at. The Internet and your favorite search engine can handle the rest. In this case, I started by copying the ErrorStatus lines that had a boolean of true into my search engine. I hit pay dirt when CERT_TRUST_HAS_WEAK_SIGNATURE pointed me to this Microsoft KB article Microsoft Security Advisory: Update for minimum certificate key length. In short, Microsoft disabled support for weak key lengths, i.e. lengths that were not equal to or more than 1024 bits. From the certificate error below, I could see that the key length for the certificate the server was using was only 512 bits long:

image

To work around the issue, we needed to enable support for weak certificates on those workstations that needed access to the site. To do this, open an elevated command prompts and type certutil -setreg chain\minRSAPubKeyBitLength 512. See the KB article for more command line options. This can also be toggled in the registry at HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config and creating a DWORD of minRSAPubKeyBitLength equal to 512.

Posted in Troubleshooting | Tagged: | Leave a Comment »

Some Quick Troubleshooting with IE Developer Debug Tools

Posted by William Diaz on August 29, 2013


I probably spent too much time trying to figure this one out, especially considering I have used the IE Developer Tools (F12) to troubleshoot IE issues in the past, and the fix would have been amazingly fast if I had employed this resource at first. The problem was that a user was unable to view patent images from a website. In the past, this site had used different file formats to send the pages to the browser, such as TIFF. However, regardless of the TIFF viewer application installed, the pages would not render in the browser. Instead there was a red x displayed indicating the image could not be loaded.

After about half an hour of troubleshooting, I went to F12, selected the Script tab in the Developer tools to see what the javascript wanted to do and saw my answer near the bottom of the script:

image

The webpage was not trying to deliver a TIFF file. Instead, it was wanted to send a PDF. The fix? Change the PDF application (Adobe in this case) to display PDFs in the browser. I also should have avoided listening to the user insisting that the problem was with TIFFs.

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