cluberti

First configure the machine for a complete memory dump, then make the problem happen and dump the box. Compress and upload the dump somewhere we can access it, and perhaps we can tell you without having to flatten your box.

Do you have a folder C:\Winnt\Installer?

OK, so with all of those things done, that much RAM shouldn't be problematic. What happens if you boot into safe mode? How long does that take?

Well, 10 minutes to boot is a little slow, and the freezing and lockups you speak of are also not normal behavior. What OS is this, and how frequently are you able to run complete virus, spyware, and malware scans on the machine? Also, how frequently is the hard disk defragmented? Oh, and how much RAM is in the box?

OK - the only other three questions I have are as follows: 1. Is the PC using the same NIC (and thus NIC driver) amongst all of these reinstalls of Windows? 2. Have you tried a Live Linux distro boot CD to see if the problem happens there? 3. Have you tried a different physical machine on this connection?

Have you tried running these in something with good VESA emulation, like DosBOX? Since the 16bit subsystem runs inside the 32bit ntvdm.exe, that error message is coming up from the ntvdm.exe process, and not command.com (which is running your app in a "virtual machine" of sorts). I would also STRONGLY suggest that you disable the previous tweaks, as they wreak havoc with 16bit apps.

Please search the forum next time - this has already been answered (the best one is below, in my humble opinion): http://www.msfn.org/board/Slipstreaming-Wi...-R2-t69617.html

64bit has no such problems. The reason you see these issues on 32bit is because you're reaching the limitations of the architecture, not the software, when you put a lot of RAM in a box (2 to the 32nd power is 4096, or 4GB - the maximum a 32bit OS can use without PAE). Don't blame Windows (or any other 32bit OS, for that matter) for having trouble with 4GB of RAM or poor memory management at that boundary under load - it's not the software's fault. Blame your hardware and software vendors for keeping the x86 architecture alive and kicking so long (32bit processors have been around since the mid 1970's!!!) - 64bit OSes were available in the Unix world from most vendors about 11 years ago, and about 8 years ago became more mainstream (although DEC had a version since 1992 for Alpha, which became Compaq Tru64). The sooner we get hardware and software vendors to realize that movement to 64bit is a good idea, the fewer issues you'll see on the memory management and memory barrier front.

Try downloading and installing the MSI 3.1 v2 installer again, or run Dial-a-fix with the "Fix Windows Installer" boxes checked to try and fix it.

If they need access to all of that, either allow VPN access and let them RDP to their workstations inside the network, or yes, install Terminal Services.

Are you using USB or Ethernet to connect the modem to the PC?

Please try running in safe mode as well for awhile too, to see if it happens there as well.

It is odd, and your initial post of sample code above doesn't have any glaring errors I can see. However, you may want to consider trying to save the register before you go in, and restore it on your way out. It's something you could try, although I'm thinking the compiler should catch it for you. Again, not sure - it's not obvious what the problem is.

If you run the box in safe mode for awhile, does it hang then? Also, describe "hang" - does it just stop responding to keyboard / mouse input, can you not move the mouse cursor, can you ping it (or not) from another box, etc?

Never a problem. Good luck!

Nvidia's drivers for the 8xxx series have been... subpar, at best, although mostly under Vista. Have you tried running the machine in VGA mode to see if the problem occurs there?

Note that these are not going to be updated for Vista / Server 2008, and most tools in the MPS Report package do not work properly on these platforms. Microsoft has moved to a tool called MSDT, which is not available publicly.

When I see code like that, it reminds me that you can have buffer overrun issues when using char *, and also, you should really be using stdcall instead of a C calling convention (like you are doing). It would be interesting for you to try and have it compile in VS 2005 or 2008.

I used windbg - to debug, you need to know a few things first: 1. Understand C/C++ and Intel x86 assembler - without understanding these, you'll have trouble reading and understanding the function names and assembly language seen in the .dmp file 2. Understand the book "Windows Internals, 4th Edition" - without understanding the innards of Windows and how it's supposed to work, recognizing "broken" becomes very difficult 3. Reading and understanding the concepts in the book "Advanced Windows Debugging" - again, unless you understand the basics of Windows and the debugger, you'll be lost quickly.

Unfortunately, you'd probably be best checking with the laptop vendor. Memory test apps are a dime a dozen, but good hardware diagnostic apps usually come from the vendor themselves.

Hmmm - the first dump (the STOP 0xa) looks like a problem with the Logitech driver calling a debug, and the STOP 0x9F dump looks like the Intel wireless driver failed an IRP check by the power manager. Are you sure the hardware in that box is OK? Otherwise, you have a LOT of bad drivers.

Isn't that a recent phenomenon? I seem to recall reading in the past year or so that they were *starting* to do that. I think it started with 2003, but I could be wrong. That's the first I remember hearing of the practice.

It's Kapersky - here's why: // Here's the thread causing the trap and crash: 1: kd> .trap 0xffffffff9db4f730 ErrCode = 00000002 eax=00000002 ebx=84068a50 ecx=00000000 edx=00000000 esi=9db4f7e0 edi=00000000 eip=823a4dae esp=9db4f7a4 ebp=9db4f7b4 iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 hal!KeAcquireSpinLockRaiseToSynch+0xe: 823a4dae f00fba2900 lock bts dword ptr [ecx],0 ds:0023:00000000=???????? 1: kd> kb *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child 9db4f7a0 8d96b855 84068a50 84068a50 86dfe590 hal!KeAcquireSpinLockRaiseToSynch+0xe 9db4f7b4 8d96b667 00000000 9db4f7e0 9db4f820 tcpip!TcpIoControlEndpoint+0xb0 9db4f7c4 8d44c729 00000000 9db4f7e0 84068a50 tcpip!TcpTlEndpointIoControlEndpoint+0x81 9db4f820 8d443294 00068a50 86dfe578 86dfe502 tdx!TdxIssueQueryAddressRequest+0x1b7 9db4f83c 8d448a63 84068a50 86dfe538 86dfe502 tdx!TdxQueryInformationTransportAddress+0x5e 9db4f85c 8d44cdd9 8402ba02 86dfe538 86dfe5a8 tdx!TdxQueryInformationConnection+0x83 9db4f878 82027f83 865e6030 86dfe538 86dfe538 tdx!TdxTdiDispatchInternalDeviceControl+0x10b 9db4f914 82081dca 9db4f948 00000200 86690213 nt!IofCallDriver+0x63 9db4f9bc 82178f44 820f7780 9db4fbe0 00000000 nt!_vsnprintf+0x18 9db4f9f8 820715e8 0000000f 844ed030 00000000 nt!FsRtlAllocateExtraCreateParameterFromLookasideList+0x63 9db4fa44 823a7518 886d7000 00000002 86f1a788 nt!EtwTraceContextSwap+0x14a 9db4fa54 82090f86 9db4fa7c 8227dd83 00000000 hal!KfLowerIrql+0x64 9db4fa58 9db4fa7c 8227dd83 00000000 00000000 nt!KiDispatchInterrupt+0xf6 WARNING: Frame IP not in any known module. Following frames may be wrong. 9db4fa5c 8227dd83 00000000 00000000 00000000 0x9db4fa7c 9db4fa7c 86f1a788 886d7002 c0026688 9db4fab4 nt!ExCreateHandle+0x32 9db4fa80 886d7002 c0026688 9db4fab4 04cd1000 0x86f1a788 9db4fa84 c0026688 9db4fab4 04cd1000 886d7002 0x886d7002 9db4fa88 9db4fab4 04cd1000 886d7002 c0600130 0xc0026688 9db4fa8c 04cd1000 886d7002 c0600130 00000000 0x9db4fab4 9db4fb94 820bf348 8437fda0 820bf6d3 9db4476c 0x4cd1000 9db4fb9c 820bf6d3 9db4476c 9db4fc44 9db4fccc nt!NtFreeVirtualMemory+0x7de 9db4fc2c 82027f83 86fda910 840551c8 87126668 nt!NtFreeVirtualMemory+0xb49 00000000 00000000 00000000 00000000 00000000 nt!IofCallDriver+0x63 // The previous thread is missing lots of info, because it's a minidump - however, we can figure it out // by walking the stack down manually: 1: kd> dds 9db4fbcc 9db4fbcc 9db4fbe0 9db4fbd0 00000000 9db4fbd4 87126668 9db4fbd8 8005210c 9db4fbdc 00000000 9db4fbe0 00000000 9db4fbe4 01ffffff 9db4fbe8 87283e91 9db4fbec 8005210c 9db4fbf0 840551c8 9db4fbf4 0000008c 9db4fbf8 840551c8 9db4fbfc 00000000 9db4fc00 87126684 9db4fc04 871266d8 9db4fc08 87126668 9db4fc0c 86fda910 9db4fc10 8005210c 9db4fc14 8d42811e*** WARNING: Unable to verify timestamp for kl1.sys *** ERROR: Module load completed but symbols could not be loaded for kl1.sys kl1+0x211e 9db4fc18 86fda910 9db4fc1c 87126668 9db4fc20 84030528 9db4fc24 86fda910 9db4fc28 9db4fc44 9db4fc2c 00000000 9db4fc30 82027f83 nt!IofCallDriver+0x63 9db4fc34 86fda910 9db4fc38 840551c8 9db4fc3c 87126668 9db4fc40 86fda910 9db4fc44 9db4fc64 9db4fc48 82188f53 nt!IopSynchronousServiceTail+0x1e0 1: kd> lmvm kl1 start end module name 8d426000 8d442000 kl1 T (no symbols) Loaded symbol image file: kl1.sys Image path: \SystemRoot\system32\DRIVERS\kl1.sys Image name: kl1.sys Timestamp: Sat Apr 28 08:50:13 2007 (46334305) CheckSum: 00025339 ImageSize: 0001C000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0 The problem here is basically that the Kaspersky driver issued a listen request to tdx.sys, which generated a security inspection of the request. The inspection was never completed, so the tdx.sys object that was given the listen request is stuck in the "listen pending" state. When tdx.sys converts from a base endpoint to a listener, it makes a NULL out the endpoint handle before issuing the request. Since we're stuck pending, and the base endpoint handle was NULL'ed before the listen request was issued, a NULL value is then passed on which causes the bugcheck. It's a long debug, but above is the relevant parts. I'm betting the Kapersky software is either not Vista compatible, or doesn't like your network card drivers if it is Vista compatible.

The only reasons I can think for this error would be either if you were attempting to install the x64 package on x86 or x86 package on an x64 box, or if you're already running the SP1 beta.

1) 0x0000000a (0x00000000, 0x00000002, 0x00000001, 0x81fa4dae) 2) 0x0000000a (0x00000000, 0x00000002, 0x00000001, 0x823a4dae) Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL The IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x0000000A. This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. These two mean a kernel-mode (hardware, antivirus, CD emulation, backup, or firewall most likely) driver did something in a way it shouldn't have when scheduling. This is bad, of course, causing a bugcheck. 3) 0x00000019 (0x00000020, 0x8521f408, 0x8521f438, 0x08060008) Bug Check 0x19: BAD_POOL_HEADER The BAD_POOL_HEADER bug check has a value of 0x00000019. This indicates that a pool header is corrupt. This means that a driver corrupted the header of a kernel pool block, causing a bugcheck the next time it was accessed. Again, a driver is malfunctioning when you see this. 5) 0x0000011d (0x00000000, 0x00000000, 0x00000000, 0x00000000) Bug Check 0x11A: EM_INITIALIZATION_FAILURE The EM_INITIALIZATION_FAILURE bug check has a value of 0x0000011A. Again, a driver failed during an initialization routine (seeing a pattern here??? ) - so, Windows isn't your problem, but a driver you're installing. 4) 0x000000c4 (0x000000b2, 0x8ebef200, 0x0000000c, 0x00000004) Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION The DRIVER_VERIFIER_DETECTED_VIOLATION bug check has a value of 0x000000C4. This is the general bug check code for fatal errors found by Driver Verifier. This one means that when you enabled verifier, a driver malfunctioned and the dump from this would have told us which driver - note that when you enable verifier, and a driver malfunctions, it is supposed to bugcheck - if you don't have the C4 dump, I'd suggest re-enabling verifier and causing another bugcheck and then uploading the .dmp file here so we can look at it.