Hello,

There is a very annoying problem with Windows 8 (and up), this issue did not exist with Windows 7 or earlier.

Basically if you go to "Network" in Windows Explorer you will (as expected) see all of your network devices - any device with a web interface should have a "View device webpage" option if you right-click it. This works fine as long as the device is http, if you try to do it with an https device it will give you an error "Error 0x80004002: No such interface supported". 

Same thing happens on all Windows 8, 8.1 and Windows 10 machines (regardless of default browser) but it works perfectly fine on a Windows 7 machine... Anyone got any idea for a workaround? The device used I'm using is a Netgear ReadyNAS but it seems to happen with any device that uses https for its admin webpage.


Really thankful for any help I can get on this!

• Edited by Hesten123 Thursday, January 22, 2015 6:42 PM

Also wondered about this but never got around to actually making a thread about it! I don't have any solution more than creating a shortcut to the device web page, would like to see if there are any other ways.

• Edited by Mzeera Saturday, January 24, 2015 6:30 PM

Hi Hesten123,

Please take the suggestion to create a shortcut as a workaround temporarily.

Currently I am not able to reproduce the issue. If available, please upload us the screenshot of this issue.

If any further helpful information, I will update here.

Best r

Hi Michael,

Thank you for the reply.. I can't put pictures in here as my account is not verified but here are three screenshots:
http://imgur.com/wsZvTWz

And when you click it, this happens (no matter what browser is set to default):
http://imgur.com/eulVKHf

This does not happen in Windows 7 on earlier with the exact same device, only in Windows 8 and later.

Here are the properties for this specific device:
http://imgur.com/WZwlYEM

Note that clicking the web address from inside the "properties" window works just fine.. The error only occurs when you right-click and then "View device webpage".

• Edited by Hesten123 Tuesday, January 27, 2015 10:05 PM

Hi Hesten123,

Thanks for the update.

So you mean this device could be accessed from the link under the properties, and could not through the right click of View Device Manager?

I suspect there might be some calling error (or configuration mistake) within this, please consider run process monitor and capture two traces through the above two connect methods, you may upload them into OneDrive and post the shared link here.

Follow the steps mentioned in the article below:

Troubleshooting with Process Monitor

Best regards

Hi Michael,

I created a .gif to better demonstrate what's happening.. Somehow I managed to make a somewhat perfect looping gif so don't get stuck watching it for too long - it does loop ;)

http://imgur.com/XFCqMpO

Also note that the media device at the end of the gif is the same device but if you check properties it uses a http link rather than a https link - if I right-click that one and press "view device webpage" it works just fine.

----

Here's a process monitor capture of me trying "view device webpage":

https://onedrive.live.com/redir?resid=22B9C7037AD2E51B!249&authkey=!AML4mAr7NaB0d2w&ithint=file%2cPML

to find the action just search for "nas", or the full hostname; nas-2B-F7-7C

Hope you can help me find a solution for this.. I guess it's related to certificates but I don't see why it's an issue on Windows 8 but not Windows 7.

• Edited by Hesten123 Thursday, January 29, 2015 7:06 PM

Hi Hesten123,

Apologize for the late reply.

Would you mind to capture the worked example that access from the link on the properties tab?

It would be more efficient to check with both of the two traces.

Once ready, you may right click on the same call and check on the properties of the call.

Check and see if any difference between them on DLL files at the process tab.

Best r

Hi Michael,

No worries! 

I made a capture using the properties window now:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B!250&authkey=!AM70JOgKJWMzYSE&ithint=file%2cPML

As far as I can tell all it does is just launch Chrome with the command line
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" https://192.168.2.123/admin/

which makes sense and what I guess "View device webpage" should be doing as well but for some reason isn't.. Any suggestion for a workaround would be greatly appreciated.

Hi Hesten123,

Apologize for the long delay.

I checked at the log files and it is hard for me to determine the root cause.

i will help to involve someone else to further look at this issue. There might be some time delay.

Appreciate you patience.

Best regards

Hi Michael,

Indeed, this one had me scratching my head for quite a while... Sure it's a small thing and there are other ways to get to the web interface but still, I think it should work.  

Great, thanks. I hope that we can find a solution - maybe some registry key that can be changed or so? Just as a temporary workaround. I'll try to get a capture while doing it on a Windows 7 machine to compare since it works fine on Windows 7.. Just not on Windows 8(.1 / or 10 for that matter).

Hi,

The below is the information shared by Mike Pei (Who is involved to solve this issue):

Based on our experience, the issue only occurs on windows 8 and later system. Windows 7 can work fine without problems. We assume the compatible issues between windows clients and NASstorage may pose this issue. Without enough information, we cannot determine if the windows side or storage caused this issue.

The system will call web explorer to open the admin page, so we may need to get the netmon traces for troubleshooting first.

1. Use the Network Monitor to collect information on the problematic client

=================================================================

1. Download Microsoft Network Monitor Tool from the following link and install it on the machine

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

1. Start Network Monitor at "Start" ->"Program"-> "Microsoft Network Monitor 3.4" -> "Microsoft Network Monitor 3.4" on the machine.
2. On the left-panel, check the "LAN connection" and uncheck the other unnecessary connections on the two machine.
3. Click "Tools", click "Options", switch to the "Capture" tap, and set the "Temporary capture file size (MB)" to 200 on the machine.
4. On the client, please run the command line below in the cmd.exe with admin permission to clear the client side cache, NetBios cache and Kerberos cache.

ipconfig /flushdns

nbtstat RR

klist purge

1. Click "New Capture", click "Start" on the Capture menu
2. Now try to reproduce the problem.
3. When the issue occurs, click "Stop" on the Capture menu on the two machines, and click "File"->"Save as" to save the captured files.
4. Please send the error screenshot which indicates the issue to me

Note: please tell me the IP addresses of client and storage device.

Let me know if you have any questions.

Regards

I made a capture using the properties window now:

Try making the two traces more comparable.  E.g. I think the Process & Thread events in the second trace could be very significant.  E.g. is Delegate_Execute.exe equally apparent in both?  For an initial filter I used  Operation Begins with Process.

Btw does this mean that Chrome is your default browser?  Have you tried a different browser?   <eg>

 

HTH

Hello Michael,

Thank you, I'll try to go through the steps provided tonight.

@Robert, I'll make two new captures right after each other. The two previous captures were made with several days in between. As for the browser, it doesn't matter which browser is the default one (same issue regardless) but yes, Chrome is my current default.

Thanks!

Hey Michael and Robert,

Here are the network monitor captures and a new set of process monitor captures (made directly after eachother)... Process monitor of the properties window is a lot bigger since that one launches Chrome (as expected) which generates a lot of data.

Info:

• Computer hostname: HEXQUAD  |  IP: 192.168.2.128
• NAS hostname: nas-2B-F7-7C | IP: 192.168.2.123
• In addition to ethernet network interface I also enabled capturing on the Virtualbox adapter since well, in this case the NAS is a virtual machine - same thing happens even if it's a real non-virtual machine. VirtualBox host-only IP: 192.168.56.1 (not sure how relevant this is though).
  

Network capture using "View device webpage":
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21251

Network capture using the link in the properties dialog:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21252

Process monitor capture using "View device webpage":
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21253

Process monitor using the link in the properties dialog:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21254

Screenshot of the issue as it occurs:
http://imgur.com/eulVKHf

.gif animation demonstrating the issue:
http://imgur.com/XFCqMpO

Thanks for your help!

• Edited by Hesten123 Thursday, February 12, 2015 7:36 PM

new set of process monitor captures

Both are still dependent on that mysterious delegate_execute.exe that you got from Chrome.

https://code.google.com/p/chromium/issues/detail?id=171355

(Google search for
    "class not registered" delegate_execute site:google.com
)

There is a possible solution in there that you could check.

 

Good luck

Hello Robert,

Please note that the same issue occurs even if another default browser has been selected. I'll get some captures while using IE as default browser later today.

Thanks!

Process captures using IE as default browser>

"View device webpage" and one click at "retry":
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21255

Using properties window:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21256

Process captures using IE as default browser>

Aha.  It's the same kind of thing, this time with something called dllhost.exe

Please try the ProcMon filter  Operation Begins with Process so you can see what I mean.

Hmm...  then I just added  Operation Begins with Thread  and saw  CCC.exe.  Is that relevant here?

You can also use the filter  Category Is Write  usefully I think.  Compare your two traces with that and do a Find (Ctrl-f) for  \admin

I really think this has more to do with the registry than with Networking.

 

HTH

Hi Hesten123,

Apologize for the late reply.

The below is the analyze result from Mike:

I just analyzed the netmon traces on fromproperties.cap and viewdevice.cap

From the GIF, I saw the client is able to open the admin page from properties and failed in click view device.

fromproperties.cap

65            0              3:12:21 AM 2/13/2015           6.4557292                               192.168.2.128         192.168.2.123         TCP          TCP:Flags=......S., SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342895909, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192 {TCP:40, IPv4:39}

66            0              3:12:21 AM 2/13/2015           6.4559219                               192.168.2.123         192.168.2.128         TCP                TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=50859, PayloadLen=0, Seq=3735137660, Ack=3342895910, Win=14600 ( Negotiated scale factor 0x3 ) = 116800    {TCP:40, IPv4:39}

67            0              3:12:21 AM 2/13/2015           6.4559988                               192.168.2.128         192.168.2.123         TCP          TCP:Flags=...A...., SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342895910, Ack=3735137661, Win=256 (scale factor 0x8) = 65536     {TCP:40, IPv4:39}

73            190          3:12:21 AM 2/13/2015           6.4585627                               192.168.2.128         192.168.2.123         TLS          TLS:TLS Rec Layer-1 HandShake: Client Hello.           {TLS:46, SSLVersionSelector:45, TCP:40, IPv4:39}

75            0              3:12:21 AM 2/13/2015           6.4587913                               192.168.2.123         192.168.2.128         TCP          TCP:Flags=...A...., SrcPort=HTTPS(443), DstPort=50859, PayloadLen=0, Seq=3735137661, Ack=3342896100, Win=1959 (scale factor 0x3) = 15672   {TCP:40, IPv4:39}

80            1152        3:12:21 AM 2/13/2015           6.4649721                               192.168.2.123         192.168.2.128         TLS          TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.; TLS Rec Layer-3 HandShake: Server Key Exchange.; TLS Rec Layer-4 HandShake: Server Hello Done.             {TLS:46, SSLVersionSelector:45, TCP:40, IPv4:39}

81            0              3:12:21 AM 2/13/2015           6.4650016                               192.168.2.128         192.168.2.123         TCP          TCP:Flags=...A...., SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342896100, Ack=3735138813, Win=252 (scale factor 0x8) = 64512     {TCP:40, IPv4:39}

94            126          3:12:22 AM 2/13/2015           6.4775177                               192.168.2.128         192.168.2.123         TLS          TLS:TLS Rec Layer-1 HandShake: Client Key Exchange.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message.                {TLS:46, SSLVersionSelector:45, TCP:40, IPv4:39}

95            258          3:12:22 AM 2/13/2015           6.4786686                               192.168.2.123         192.168.2.128         TLS          TLS:TLS Rec Layer-1 HandShake: Encrypted Handshake Message.; TLS Rec Layer-2 Cipher Change Spec; TLS Rec Layer-3 HandShake: Encrypted Handshake Message. {TLS:46, SSLVersionSelector:45, TCP:40, IPv4:39}

96            0              3:12:22 AM 2/13/2015           6.4787183                               192.168.2.128         192.168.2.123         TCP          TCP:Flags=...A...., SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342896226, Ack=3735139071, Win=251 (scale factor 0x8) = 64256     {TCP:40, IPv4:39}

114          0              3:12:22 AM 2/13/2015           6.4893397                               192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A...F, SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342896226, Ack=3735139071, Win=251 (scale factor 0x8) = 64256   {TCP:40, IPv4:39}

120          31            3:12:22 AM 2/13/2015           6.4903987                               192.168.2.123         192.168.2.128         TLS          TLS:TLS Rec Layer-1 Encrypted Alert          {TLS:46, SSLVersionSelector:45, TCP:40, IPv4:39}

121          0              3:12:22 AM 2/13/2015           6.4904282                               192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A.R.., SrcPort=50859, DstPort=HTTPS(443), PayloadLen=0, Seq=3342896227, Ack=3735139102, Win=0 (scale factor 0x8) = 0              {TCP:40, IPv4:39}

viewdevice.cap

443 (0x1BB)            24            0              3:11:01 AM 2/13/2015           2.3067099               System    192.168.2.128         192.168.2.123         TCP                TCP:Flags=......S., SrcPort=50852, DstPort=HTTPS(443), PayloadLen=0, Seq=3369775565, Ack=0, Win=65535 ( Negotiating scale factor 0x8 ) = 65535          {TCP:13, IPv4:12}

50852 (0xC6A4)      25            0              3:11:01 AM 2/13/2015           2.3068862               System    192.168.2.123         192.168.2.128         TCP                TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=50852, PayloadLen=0, Seq=2371583130, Ack=3369775566, Win=14600 ( Negotiated scale factor 0x3 ) = 116800    {TCP:13, IPv4:12}

443 (0x1BB)            26            0              3:11:01 AM 2/13/2015           2.3069814               System    192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A...., SrcPort=50852, DstPort=HTTPS(443), PayloadLen=0, Seq=3369775566, Ack=2371583131, Win=1024 (scale factor 0x8) = 262144 {TCP:13, IPv4:12}

443 (0x1BB)            27            156          3:11:01 AM 2/13/2015           2.3072129               System    192.168.2.128         192.168.2.123         TLS                TLS:TLS Rec Layer-1 HandShake: Client Hello.      {TLS:15, SSLVersionSelector:14, TCP:13, IPv4:12}

50852 (0xC6A4)      28            0              3:11:01 AM 2/13/2015           2.3072962               System    192.168.2.123         192.168.2.128         TCP                TCP:Flags=...A...., SrcPort=HTTPS(443), DstPort=50852, PayloadLen=0, Seq=2371583131, Ack=3369775722, Win=1959 (scale factor 0x3) = 15672   {TCP:13, IPv4:12}

50852 (0xC6A4)      29            1338        3:11:01 AM 2/13/2015           2.3112361               System    192.168.2.123         192.168.2.128         TLS                TLS:TLS Rec Layer-1 HandShake: Server Hello.; TLS Rec Layer-2 HandShake: Certificate.; TLS Rec Layer-3 HandShake: Server Key Exchange.; TLS Rec Layer-4 HandShake: Server Hello Done. {TLS:15, SSLVersionSelector:14, TCP:13, IPv4:12}

443 (0x1BB)            30            0              3:11:01 AM 2/13/2015           2.3112979               System    192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A...., SrcPort=50852, DstPort=HTTPS(443), PayloadLen=0, Seq=3369775722, Ack=2371584469, Win=1018 (scale factor 0x8) = 260608 {TCP:13, IPv4:12}

443 (0x1BB)            37            0              3:11:01 AM 2/13/2015           2.3190298               System    192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A...F, SrcPort=50852, DstPort=HTTPS(443), PayloadLen=0, Seq=3369775722, Ack=2371584469, Win=1018 (scale factor 0x8) = 260608         {TCP:13, IPv4:12}

50852 (0xC6A4)      38            0              3:11:01 AM 2/13/2015           2.3193700               System    192.168.2.123         192.168.2.128         TCP                TCP:Flags=...A...F, SrcPort=HTTPS(443), DstPort=50852, PayloadLen=0, Seq=2371584469, Ack=3369775723, Win=1959 (scale factor 0x3) = 15672           {TCP:13, IPv4:12}

443 (0x1BB)            39            0              3:11:01 AM 2/13/2015           2.3194104               System    192.168.2.128         192.168.2.123         TCP                TCP:Flags=...A...., SrcPort=50852, DstPort=HTTPS(443), PayloadLen=0, Seq=3369775723, Ack=2371584470, Win=1018 (scale factor 0x8) = 260608 {TCP:13, IPv4:12}

After comparing the packets, we can see after TCP three handshakes completes and certificate exchange finishes, the client did not send the client key exchange information to the NAS device when click on view device to open the admin page. However, we can see this behavior when trying to open the page from properties.

From the GIF, we can see the client failed to download one file from NAS with third party explorer chrome, since the traffic is encrypted, we cannot see the actual information.

For we are not familiar with google products, could you please set the windows IE explore as default explorer and make sure the system will launch IE when click on view device.

We have to exclude the possibility that the issue is caused by chrome first.

Best regards

Hi Michael,

Thank you for continued help on this. I don't know if you saw my previous post, it contains process monitor captures using IE instead of Chrome. I will be away this weekend and can't provide network captures but I will provide them as soon as possible.

But please note that this issue is the exact same even on a system that does not even have Chrome installed, to me it seems unrelated to the browser.

Hi Hesten123,

What is your current situation by now

Best regards

Hi Michael,

No progress, been a busy weekend and start of week. I'll get the captures tonight.

Thanks!

Hi Michael, 

Finally got the IE captures as well. Linking the process captures again too. 

Setup is same as before:
Computer hostname: HEXQUAD  |  IP: 192.168.2.128
NAS hostname: nas-2B-F7-7C | IP: 192.168.2.123
In addition to ethernet network interface I also enabled capturing on the Virtualbox adapter since well, in this case the NAS is a virtual machine - same thing happens even if it's a real non-virtual machine. VirtualBox host-only IP: 192.168.56.1 (not sure how relevant this is though).

Process capture of "View device webpage" and one click at "retry" while IE is standard browser:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21255

Process capture using properties window while IE is standard browser:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%2125


Network capture of "View device webpage" while IE is standard browser:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21258

Network capture using properting window while IE is standard browser:
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21257


And once again I'd just like to point out that this exact same device and setup works just fine on Windows 7, just not on Windows 8 (or 10 RC).

Thanks!

Hi Michael,

Did you see the captures? Any ideas? I'd say the issue is with Windows, something was changed with the way https are opened from Network explorer when Windows 8 was released... Question is if the change can be tracked and reverted or if someone can figure out some sort of workaround?

Hi Hesten123,

Apologize for the long delay reply.

This monring I received the message from Mike:

I just finished the packet and promon analysis.

Here is the result.

From property

From device

I dont see any traffic between 192.168.2.128 and 192.168.2.123 from two packets.

Promon logs

From the process monitors logs collected when clicking to view Device.

There is no error or failure results in it.

Action plan

========

We may need to collect the desired information again. please help gather the netmon traces and process monitor logs again.

Best regards

Hi Michael,

Alright.. Maybe related to the device in question being a virtual machine hosted on the same computer as I'm doing the tests from. I'll bring home a physical device from work today or tomorrow and do another capture. Thanks!

 please help gather the netmon traces and process monitor logs again.

How about getting an explanation for those  Operation Begins with Process  discrepancies that I found first?

E.g. what are Google's  delegate_execute.exe and W8's dllhost.exe supposed to be starting?

Hello Michael,

I have now made new captures.. Both process and network while using IE as the default browser and also using an actual physical unit rather than a VM. I'm not sure we'll find the answer in the netcaps, I think Robert may be on to something.

Anyways, here they are (put everything in to one archive this time):
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21259

Setup this time is as follows:
Client hostname:  HEXQUAD      Client IP:  192.168.2.123
Device hostname: LAB314         Device IP: 192.168.2.133

Hopefully this will be helpful.

• Edited by Hesten123 Wednesday, March 11, 2015 8:41 PM

Hi all,

I have sent the message to Mike.

If any update, will post back.

Best regards

Hi Hesten123,

The trace result you uploaded contains no related informations in Network monitor and the process monitor,

The message from Mike:

In the network trace, client use dynamic port 55549,55550,55551 to communicate with 192.168.2.133

But from the process monitor logs, the client use TCP port 55554, 55555, 555556:

We need to collect the netmon trace and promon logs at the same time.

Whats more, from the GIF file. I see the IE tried to download one file from NAS server. But I did not see this behavior in netmon trace.

Apologize for any inconvenience.

Regards

Hi Michael,

Alright - so here are new captures.. All running at the same time; process monitor, network monitor and also gifcam to demonstrate exactly what is being done.
https://onedrive.live.com/redir?resid=22B9C7037AD2E51B%21262

Setup is same as above;
Client hostname:  HEXQUAD      Client IP:  192.168.2.123
Device hostname: LAB314         Device IP: 192.168.2.133

Anything missing/mismatching between the captures now would be an issue with Windows - all captures at taken at the exact same moment. Hopefully this will help more :-)

To make things easier and if you want to reproduce it on your side, here's a guide on how to install a readynas in VirtualBox;
http://apps.readynas.com/pages/?page_id=143

I can also be available for remote session if that's required.

Cheers!

• Edited by Hesten123 Monday, March 16, 2015 6:22 PM

Hello Michael,

Just wanted to check if you saw my latest message and if it's been forwarded?

Cheers!

Hi Hesten123,

Apologize for the late response.

I might missed the Alert of your update.

Further, this case is under process discussion, I will forward the information you posted.

Thank you for your patience and understanding.

Best regards

Hi Michael,

Just curious if there's been any update on this case? Thank you

Since the alerts for this thread doesn't seem to work (at least I never got any myself) I'm bumping this one again. Cheers!