1 of 1 people found this helpful
What is the driver version showing in Windows Device Manager? I am guessing you are using the version 184.108.40.206 driver that Microsoft provided as part of Windows 8. The next version of the Intel web packs that is coming out soon, probably within the next week or two. The new version, version 17.4, will automatically install the latest generic e1e Windows 7 driver for you on your Windows 8 system.
Installing the latest Windows 7 driver in Windows 8 might solve your issue, but with built in network connections you never know if a driver update will help. Do you know if HP supports Windows 8 on your laptop? If not, you might not get everything working properly under Windows 8. Even if HP does not support Windows 8, you might find it worthwhile to make sure you have the latest BIOS version. Sometimes those updates also have changes that affect the network connection.
yes i used the default windows 8 network driver i will install windows 8 again and check for the latest driver from here , i don't think HP Will Support My Device For Windows 8, So i Came Here To My Network Card Driver Manufacturer To Get Some Help
Any Way Thanks Sir I'll Try And Post My Answer Here
There is a very similar issue reported here:
Meanwhile driver version 17.4 has been released. It installs fine on Windows 8 but does not solve the issue at all. Always when running in battery-mode the machine freezes a few seconds every 3-10 seconds and therefore is unusable.
Some Intel engineers did investigate this issue and this is what they found. When the system is in battery mode to save power, Windows 8 is doing something different compared to Windows 7 and earlier versions of Windows. For some reason the driver is not getting called by the OS in battery mode resulting in transmit hangs.
I do not anticipate any driver update for this issue, but you should be able to make a registry change to the interrupt type from MSI to legacy to work around the issue. After disabling MSI on a test machine here, the hang was no longer happening.
MSI can be disabled from registry. You can use Windows Device Manager to find the hardware device ID information that will be part of the path to the registry setting shown in brackets and highlighted below. Hardware IDs can be found in the device's "Details" tab.
Here is an example for my network connection. The numbers are different because I have a different network connection, but this does show where to find the hardware IDs.
The above information is what you will need from your network connection in order to locate the right place in the Windows registry.
Caution: Make sure you back up your registry before proceeding. Changing or deleting registry keys can have unintended consequences.
Registry Setting Path:
Change "MSISupported" value to '0'. The value is '1' by default. You can always go back and change to '1' again if you run into any new issues.
Here is a screen shot of my registry setting that I navigated to using the hardware IDs I found in Windows device manager:
I hope this helps.
Many thanks to you and the Intel team for investigating. I have tried this on my 82566MM chip in my HP 8510w Laptop and I can confirm that within the (short) testing period of about 5 minutes I did not experience any hangs and freezes any more.
Not sure though whether this is Windows 8 or driver bug. I guess the driver could at least "announce" to the OS that MSI is not supported properly and therefore disable it during driver installation.
Perhaps MSI will work on certain hardware and doesn't on other. Then it's a question where the bug originates. Is it firmware/BIOS/EFI or hardware (even hardware revision) related?
Intel could also add at least an advanced option to device manager properties (ProSET) in order to allow MSI support to be disabled in case of issues.
Thank you again for coming up with the solution. Although the underlying problem seems not to be resolved and many people might not find this information here on the board and still suffer from the issue as long as no driver update is officially released which fixes the problem.
Hi Mark, I'm having this same problem with windows PE 4.0 32-bit (based on same core Windows version as W8) but unfortunatley in this case I cannot use this workaround of disabling MSI operating on registry since this means restarting the machine and when WinPE boots it doesn't keep any previuos changes made by user, but it will re-discover the devices and install their drivers. And since the driver is signed I'm afraid I cannot modify the inf file in order to force the MSI setting during plug and play phase. But I'll give a try
Actually i'm using DriverVer=06/19/2013,9.16.10 (e1e6232.INF)
I've changed the inf file (e1e6232.INF) in the driver store repository (in my system the path is "Windows\System32\DriverStore\FileRepository\e1e6232.inf_x86_313433dc77078bcc") of my WInPE4.0.system
The change consisted in mounting the correspondig wim file, editing the e1e6232.inf file in order to specify the "0" value" for the "MSISupported" item:
HKR, "Interrupt Management\MessageSignaledInterruptProperties", MSISupported, 0x00010001, 0
and committing the change to the wim. Now WinPE4.0 boots and performs without pervasive temporary hangs. Curiosly (form me) the tampered inf in the driver store didn't stop the driver installation and loading.
Thanks for sharing. Maybe this is one time Windows isn't checking for a modified inf file.
The tampering unchecking may be because of we are talking about WinPE (and not "full" Windows 8) or because is a win 32 bit platform (where driver signing is not mandatory) or both. benato
In the next days I'll try changing some of these conditions.
By the way, the same workaround of disabling MSISupport succeded with the built-in ndis6.0 driver that came with Winpe4.0 (e1e6032.sys, nete1e32.inf, DriverVer=04/19/2011,220.127.116.11). In this case, just to be sure about the extension of tampering unchecking, I changed the inf file in three different locations. This may be innecessarily overscoped for our goal of influencing plug and play configuration but as i said, I wanted to evaluate the scope of inf checking).
Actually I also checked that changing only the second "inf" (the one stored in driver store repository) it's sufficient to have the "msisupported" feature disabled.
Thanks a lot Mark. I was facing the issue of disconnection in Windows 10 x64 for past more than 2 week with the same LAN adapter, and was getting completely hopeless with the situation. Already had my Windows 7 media out to revert back to the older version. Your solution worked for me like a charm. Half day has passed and not a single disconnection, and I am still on Windows 10 x64.
Thanks a bundle again. I have also quoted your solution to Microsoft support communities for Windows 10 for others to get benefit of it.
Thanks for the feedback. I'm glad to hear this works for the older network connections on Windows 10.
Thanks Mark! This fixed an elderly Toshiba Tecra A9 running Win 10. Thanks again.