Because of the nature of the issue you are experiencing and to better assist you, I'd like for you to call us so we can speak directly with you. In North America, we can be reached at (916) 377-7000, option #6.
Telephone numbers for Intel® Support Centers worldwide can be found at:
Also here is the analysis from WinDbg:
0: kd> !analyze -v
* Bugcheck Analysis *
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arg1: fffff88004805c4d, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880070c2a90, address which referenced memory
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80132557168
GetUlongFromAddress: unable to read from fffff801325571f8
fffff88004805c4d Nonpaged pool
fffff880`070c2a90 8b4500 mov eax,dword ptr [rbp]
TRAP_FRAME: fffff80132158540 -- (.trap 0xfffff80132158540)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000000000f5f7 rbx=0000000000000000 rcx=fffffa8003e7b128
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880070c2a90 rsp=fffff801321586d0 rbp=fffff88004805c4d
r8=0000000000000000 r9=0000000000000000 r10=fffff88007752b80
r11=fffffa8003e7b050 r12=0000000000000000 r13=0000000000000000
iopl=0 nv up ei pl zr na po nc
fffff880`070c2a90 8b4500 mov eax,dword ptr [rbp] ss:0018:fffff880`04805c4d=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff8013227b369 to fffff8013227c040
fffff801`321583f8 fffff801`3227b369 : 00000000`0000000a fffff880`04805c4d 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff801`32158400 fffff801`32279be0 : 00000000`00000000 fffff880`047f6588 fffff801`32158600 fffff801`32158540 : nt!KiBugCheckDispatch+0x69
fffff801`32158540 fffff880`070c2a90 : fffff880`047f6588 fffff880`04805c4d fffffa80`06542000 fffff880`047f664e : nt!KiPageFault+0x260
fffff801`321586d0 fffff880`047f6588 : fffff880`04805c4d fffffa80`06542000 fffff880`047f664e 00000000`00000000 : netwlv64+0x79a90
fffff801`321586d8 fffff880`04805c4d : fffffa80`06542000 fffff880`047f664e 00000000`00000000 00000000`00000000 : 0xfffff880`047f6588
fffff801`321586e0 fffffa80`06542000 : fffff880`047f664e 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff880`04805c4d
fffff801`321586e8 fffff880`047f664e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffffa80`06542000
fffff801`321586f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`053ffd80 : 0xfffff880`047f664e
fffff880`070c2a90 8b4500 mov eax,dword ptr [rbp]
Same Problem here on Asus V1SN using the same wireless adapter.
Crashdump also points to netwlv64.
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arg1: 0000000000000021, the data following the pool block being freed is corrupt. Typically this means the consumer (call stack ) has overrun the block.
Arg2: fffffa80081dc000, The pool pointer being freed.
Arg3: 0000000000001010, The number of bytes allocated for the pool block.
Arg4: ce0dca6d6158e85c, The corrupted value found following the pool block.
LAST_CONTROL_TRANSFER: from fffff801b8af2898 to fffff801b88fd040
fffff880`009d3548 fffff801`b8af2898 : 00000000`00000019 00000000`00000021 fffffa80`081dc000 00000000`00001010 : nt!KeBugCheckEx
fffff880`009d3550 fffff880`04c06c8a : fffffa80`081dc000 fffffa80`0842bde0 00000000`00000000 fffff880`4d746e49 : nt!ExFreePool+0x792
fffff880`009d3630 fffffa80`081dc000 : fffffa80`0842bde0 00000000`00000000 fffff880`4d746e49 00000000`00000000 : netwlv64+0x2c8a
fffff880`009d3638 fffffa80`0842bde0 : 00000000`00000000 fffff880`4d746e49 00000000`00000000 fffff880`04c86841 : 0xfffffa80`081dc000
fffff880`009d3640 00000000`00000000 : fffff880`4d746e49 00000000`00000000 fffff880`04c86841 fffffa80`067acf08 : 0xfffffa80`0842bde0
fffff880`04c06c8a ?? ???
1: kd> lmvm netwlv64
start end module name
fffff880`04c04000 fffff880`0533e000 netwlv64 T (no symbols)
Loaded symbol image file: netwlv64.sys
Image path: \SystemRoot\system32\DRIVERS\netwlv64.sys
Image name: netwlv64.sys
Timestamp: Mon Aug 16 16:26:39 2010 (4C694A9F)
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
SAME PROBLEM. Windows8 aplication say that not problems of compatibility on hardware and it not works!!.
continuos drop of connections and i must restart to work again. after restar it only work a couple of minutes.
i have to wifi one 5ghz and other in 2.4. same problems in both networks
same problems with the latest drivers (15) and the windows drivers.
please we need a solution
I'm also having issues. I have a Dell XPS M1530 which I've upgraded to Windows 8 x64.
With the driver it automatically picked up during the install (22.214.171.124) it dropped the WiFi connection within minutes of connecting.
I then tried installing the PROSet driver package from the Dell Driver Download site. The driver is dated 08/08/2007 and is version 126.96.36.199.
It seems to have improved things a little but it's still really slow and dropping out.
I downloaded the latest version 15.2.0 direct from Intel site and that won't even install...it says it can't upgrade the existing version, even after I manually uninstalled the existing version and the uninstalled the driver from the card.
I don't know if it's netwlv64.sys as reported here, I'm not very technical. I don't actually know what a BSOD is!
Please help, any ideas?
Think it will ever be supported or do I need to go back to Windows 7? :-(
Ouch, just stumbled across this:
Here's the snippet below, says 4965AGN is not supported in Windows 8.
But the note says something about an inbox driver that works with Windows 8. What is an inbox driver????
Which Intel® wireless adapters are not supported in Windows 8?
Intel® WiFi/WiMAX Link 5150
Intel® WiFi/WiMAX Link 5350
Intel® PRO/Wireless 2200BG Network Connection
Intel® PRO/Wireless 2915ABG Network Connection
Intel® PRO/Wireless 3945ABG Network Connection
Intel® Wireless WiFi Link 4965AGN
Note: The Intel® PRO/Wireless 3945ABG Network Connection and the Intel® Wireless WiFi Link 4965AGN adapters have an inbox driver that works with Windows 8. However Intel Customer Support does not support the use of Windows 8 with any of the above adapters.
"have an inbox driver that works with Windows 8" -> So should we consider random BSOD's a new standard of "working drivers". After being many years having to cope with this mediocre support then they decide to stop supporting it before fixing any bug during the whole lifecycle of this product. I'll take it mind for my next purchases and recommendations. I thought it was impossible to pass AMD in poor support but definitely Intel has reached a new milestone.
I have had exactly the same issue on an HP latop that has the intel 4965AGN. I've tried quite a few things like trying to use the windows 7 x64 driver for this card. They didn't seem to go on properly. I then read some stuff in the following post "Intel 4965AGN - Wireless drops out with Windows 7 until restart", which lead me try try disabling 802.11n, and simpy using 802.11g. In device manager, for this adapater, under the advanced tab, their is an item called "802.11n mode". I changed it from enabled to disabled. I am using the intel driver that i think came with windows 8, being 188.8.131.52. There is also a microsoft driver on the system which is 184.108.40.206 but i'm not using that. Anyway after disabling 802.11n things seem good. I've manged to download a 3.5Gb iso coming in at about 12 to 13 Mb/s and another of about 1.5GB. No drop out so far, whereas prior to this is was very frequently dropping and i could only get through 40 of 50 Mb of download before it died. I have also tried re-enabling 802.11n and the problem comes back again. Its turned off again now and seem stable so far. I hope this helps out.