cluberti

No, I don't think it's RAM related at all, and I'm not sure I know enough yet to say your antivirus has anything to do with it. As to userdump, if it doesn't work, just follow my instructions here for adplus on gathering a dump from a process that is crashing. It might take awhile and a few tries, but it should work.

Disable network auto detection and force the mode to 1000Mbps/full duplex in the driver's properties?

Well, I can't make heads or tails of the culprit, but I can tell you why it's crashing: // The stack - eip points to an invalid memory address, so we crash with an access violation: 0:014> kb ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 00fcfba4 7e418734 002c0272 00000218 0000000a 0x35b23ac 00fcfbd0 7e418816 011c0fef 002c0272 00000218 user32!InternalCallWinProc+0x28 00fcfc38 7e4189cd 00000000 011c0fef 002c0272 user32!UserCallWinProcCheckWow+0x150 00fcfc98 7e418a10 00fcfcd8 00000000 00fcfcc0 user32!DispatchMessageWorker+0x306 00fcfca8 75f9d875 00fcfcd8 00000000 021c6548 user32!DispatchMessageW+0xf 00fcfcc0 75fa5218 00fcfcd8 0007dfe0 00000000 browseui!TimedDispatchMessage+0x33 00fcff20 75fa5389 00123aa8 0007dfe0 774fd9dd browseui!BrowserThreadProc+0x336 00fcffb4 7c80b713 00123aa8 0007dfe0 774fd9dd browseui!BrowserProtectedThreadProc+0x50 00fcffec 00000000 75fa5339 00123aa8 00000000 kernel32!BaseThreadStart+0x37 0:014> dc eip L1 035b23ac ???????? ???? // In looking at the return value in EAX, I can see that it is likely supposed to be // the base address of the module that is needing to be called back - 7ffa7000: 0:014> r eax=7ffa7000 ebx=00000000 ecx=011c0ff4 edx=00000043 esi=011c0fef edi=00fcfc0c eip=035b23ac esp=00fcfba8 ebp=00fcfbd0 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 035b23ac ?? ??? // However, this address is no longer occupied by a loaded module: 0:017> dc 7ffa7000 L1 7ffa7000 ???????? ???? // In looking around the running threads in the dump, I can see some module called // the endthreadex function to terminate a thread (likely during it's dll unload routine): 0:017> kb ChildEBP RetAddr Args to Child 0113fdbc 7c90df2c 7c809574 00000002 0113fde8 ntdll!KiFastSystemCallRet 0113fdc0 7c809574 00000002 0113fde8 00000001 ntdll!NtWaitForMultipleObjects+0xc 0113fe5c 7e4195f9 00000002 0113fe84 00000000 kernel32!WaitForMultipleObjectsEx+0x12c 0113feb8 6c1e4b52 00000001 0113feec ffffffff user32!RealMsgWaitForMultipleObjectsEx+0x13e 0113fed8 6c1e4d9c 000004ff ffffffff 00000001 duser!CoreSC::Wait+0x3a 0113ff0c 6c1de344 0113ff4c 00000000 00000000 duser!CoreSC::xwProcessNL+0xab 0113ff2c 6c1da73d 0113ff4c 00000000 00000000 duser!GetMessageExA+0x44 0113ff80 77c3a3b0 00000000 7c910000 7c912cae duser!ResourceManager::SharedThreadProc+0xb6 0113ffb4 7c80b713 04911cc0 7c910000 7c912cae msvcrt!_endthreadex+0xa9 0113ffec 00000000 77c3a341 04911cc0 00000000 kernel32!BaseThreadStart+0x37 // Note that there are two other duser threads in a wait that this thread is waiting on, // but I cannot tell what the wait is on due to the fact that this is a dr watson dump, // rather than something useful like an adplus dump or a userdump dump. However, // I am suspecting that the wait is on the offending thread I listed first: 0:014> kb ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 00fcfba4 7e418734 002c0272 00000218 0000000a 0x35b23ac 00fcfbd0 7e418816 011c0fef 002c0272 00000218 user32!InternalCallWinProc+0x28 00fcfc38 7e4189cd 00000000 011c0fef 002c0272 user32!UserCallWinProcCheckWow+0x150 00fcfc98 7e418a10 00fcfcd8 00000000 00fcfcc0 user32!DispatchMessageWorker+0x306 00fcfca8 75f9d875 00fcfcd8 00000000 021c6548 user32!DispatchMessageW+0xf 00fcfcc0 75fa5218 00fcfcd8 0007dfe0 00000000 browseui!TimedDispatchMessage+0x33 00fcff20 75fa5389 00123aa8 0007dfe0 774fd9dd browseui!BrowserThreadProc+0x336 00fcffb4 7c80b713 00123aa8 0007dfe0 774fd9dd browseui!BrowserProtectedThreadProc+0x50 00fcffec 00000000 75fa5339 00123aa8 00000000 kernel32!BaseThreadStart+0x37 The reason I believe this to be the case is because the process would only be running a thread going through user32!InternalCallWinProc if it was going to report back to an unloading module before finishing up the dll unload cleanup. What it looks like is that the module just unloaded itself after calling it's unload routine, without waiting for the cleanup and callback to finish (which it is supposed to do). What I can suggest is installing userdump and create a new crash rule for explorer.exe, and only monitoring for "access violation" or "c0000005" in the rule. Dr Watson will not break in fast enough to show us the 3rd party module that is causing this, but userdump is likely to do so. One thing you can try to do though, is see if you can remember installing anything before you noticed the symptoms occurring. Otherwise, try userdump.

OK, after looking at these 4, I can say that they're ALL memory corruption errors - some are single bit errors, and some are actually multi-bit memory errors. Vista since the RC1 builds has included memory integrity checking, and I believe that sometime in one of the post-RC1 builds this was actually finalized and included in the product. First, a little memory management knowledge in case you don't know how this works. This involves pages that are coming from or being placed on the zeroed pages list. A "zeroed" page is a memory page that has been unmapped from virtual memory by the kernel memory manager, and has been placed on a list of available pages in memory that will be available to any process or driver that requests pages for allocation. The memory integrity checker works, on a high level, as follows - the memory manager first writes zeroes to the page, then checks the page to make sure it's still zeroes. If not, it'll bugcheck. If the page is still zeroes, it goes on the list to be allocated later. When the page is ready to be allocated later, it is again checked to see if it's zeroes before it's reallocated, and if it's not the machine will bugcheck. Your machine is bugchecking on the second check, meaning the pages are being corrupted while they're unused. This is very much not common . The bugchecks you have sent all include bit errors, meaning that it is quite unlikely that this is a driver problem. While it is possible a driver could potentially cause single-bit memory errors (due to causing a DMA transfer to an incorrect physical address, for instance, or a kernel-mode driver that writes to incorrect virtual addresses, causing pages to be non-zero), it's not likely. I believe back during the betas and RC builds of Vista, customers who reported this error via OCA were actually sent an invite into a program to "help Microsoft test the Windows memory diagnostic tool", if I remember correctly. Almost all of the people who ran this tool on machines that exhibited multi-bit errors found hardware problems on the system, mostly memory problems (I believe it was 75%+, but I don't think Microsoft makes these numbers public anymore as all the beta sites are gone). At this point, knowing that the problem occurs on a specific machine under both Vista x86 and x64, I would run something like memtest86+ to check the RAM in your box, and also perhaps contact the vendor of the machine to see about any other diagnostic tools they may have. The likelihood that you have some potentially unstable RAM in that machine is fairly high.

Any way you could post an actual .dmp file?

In looking at the vendor's support site, I see nowhere that they write x64 drivers for this product - only x86. So, unless you can find another vendor that uses the same internals that writes an x64 driver you can use, you will likely be out of luck. There's a list of vendors who make products based on this chipset here. Good luck.

You might be able to configure a default profile, but there's no way (I'm aware of) to edit the registry of a WIM file in an offline state. Personally, I use a vbscript to load up the default user ntuser.dat hive, make the changes, unload it, and then create my new user and disable the admin account (plus install software, patches, et al and reboot). That way all users get the default settings.

I've always found high schools to be the absolute worst places to try and build self-esteem. If you can make it out and go to college (or hit the "real world"), you'll find people are far less shallow. Just force it if you have to, but get yourself through that last year and it'll be the best thing you've ever done for yourself.

1. Transportation - can anyone at the school swing by to grab you on the way? If not, is there any public transport in your area? Assuming it's not a private school, you should be able to get the public school to either provide you transport, or get them to help you find it. Assuming you're in the US, they do have some obligations to get you to school if they can't bus you in. I don't know the limitations, but they do exist IIRC. 2. Job can wait unless you're living alone, focus on school if you can. 3. If you do find it impossible to sit still (as you say you do), get a second (or third) opinion. That is not normal, and if you don't like one doctor, see another. Unless 3 or 4 tell you the exact same thing, don't just trust one opinion.

I'll probably come off sounding like the old man I am, but I would state that you should not let circumstances define you, you should strive to define your circumstances. I am not sure I completely understand your lot in life, as I am not privy to the intricate details above and beyond what you've stated, but I get the feeling that the change (complete) in your life has left you feeling detached, with no desire to go back to something that should be familiar and easy, but is (for many reasons) not.As a broken record once emminated, your education (especially high school) is about the only thing in life that I would state you should not give up on, no matter what. I don't know if there is an underlying reason for this (that a professional can help you with), but you likely have a guidance counselor that you could discuss these things with. Failing that, there will (hopefully) be someone at the school in a position of leadership who can help you address your issues and work around them. I would hate to see you hampered in life because you were unable to find a way to finish one class (whether that be high school or college, but failing to finish high school will have far-reaching consequences, whereas failing to finish college likely would not in most cases). You seem like an intelligent person to me, able to understand there's an issue you need to address - I would suggest you address the lack of motivation issue first. That really seems like it underscores the other issues you describe, and if you can find someone to confide in on a personal level and work through this, I am hoping you will find the will to stick it out and finish up. Good luck kid, our thoughts are with you.

When do you get these warnings, and what is the exact wording? Virtual memory doesn't necessarily mean the paging file - you could be low on kernel pool, or desktop heap, for instance, and these would have nothing to do with the paging file or kernel paging (and judging from your statements, I suspect it in fact has nothing to do with RAM or paging file).

I don't know how I missed this back in the day. This exists, even on Vista and 2008, and if you physically set it you are causing the memory manager to call MmProbeAndLockPages to lock physical memory for stricly I/O operations (note that unlike drivers that call VirtualLock, these pages cannot be released back to the system if load requires). It's determined on boot based on the amount of RAM in the system how much is locked. It used to be 512K in NT3.x and 4.x, with newer OSes this may have been reduced further. Note that setting a high value might increase performance, but especially on lower-memory systems this can cause resource exhaustion (no one but the I/O manager can use these locked pages, so you increase the risk that you could cause the system to be starved for resources if it gets too busy for the memory at hand, and you'll either start paging frequently or potentially bugcheck.

Apparently you're ignoring me. Until you get a dump file using the instructions in the link I've posted twice, you will get no further assistance from me. You're asking us to guess at your problem at this point, without providing anything of value in the way of data for us to help you.

Well, if you want to know what it does (at least with public APIs and MSDN searching), use procmon to monitor the sc command doing whatever it is you want to trace, and then configure it for the public symbol server and you can see callstacks. Public symbol server notation for procmon is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols(insert whatever local folder you want to use to cache symbol info for "c:\symbols", of course)

What happens if you open a 32bit command prompt and run your script from there? I am not sure if there is a 64bit version of that file, but I'll check. As to subinacl, it currently does not support x64 systems.

@dilip1

Having a bias (or even a grudge) doesn't mean the information is inaccurate. And, from somewhat inside knowledge, his story is for the most part quite true and easy to prove. He's a journalist, yes, and has a grudge against nVidia it seems, yes. But the story still has truth. Having a bias does not necessarily make you wrong.

Considering these are memory corruption errors, yes. It would have been wise to have let us know this, although from the fact you aren't running an nVidia chipset and you're getting memory errors I'd say it seems more probable.

How about disabling Large Send Offload in the network driver's properties, and then running the following commands: netsh interface tcp set global rss=disabled netsh interface tcp set global autotuninglevel=disabled If the clients are Vista or Server 2008 boxes, run the commands there as well. If these work, you have network driver problems and somewhere along the line I suspect a broadcom NIC chipset...

I'm using 2 30" and one 20" (vertical). HD monitors are great, but if you can have 2, why not? "These go to 11"

Definitely monitors. Can't live without at least two (and I'm up to three now... yeah, that's where the $ goes, I guess ).

If you don't have the requisite resource kit, the .dll will not exist. It can be downloaded from the link I posted.

I actually noticed something very interesting on the stack: 3: kd> k Child-SP RetAddr Call Site fffff980`113dc498 fffff800`01c4da33 nt!KeBugCheckEx fffff980`113dc4a0 fffff800`01c4c90b nt!KiBugCheckDispatch+0x73 fffff980`113dc5e0 fffff800`01c8e3b0 nt!KiPageFault+0x20b fffff980`113dc778 fffff800`01c7cfe7 nt!MiFindNodeOrParent fffff980`113dc780 fffff800`01cd576e nt!MiLocateAddressInTree+0x17 fffff980`113dc7b0 fffff800`01ce44fe nt!MiIdentifyPfn+0x77b fffff980`113dc850 fffff800`01fb3965 nt!MmQueryPfnList+0x13e fffff980`113dc890 fffff800`01e38c9c nt!PfpPfnPrioRequest+0x115 fffff980`113dc8e0 fffff800`01ec06ac nt!PfQuerySuperfetchInformation+0x1db fffff980`113dc950 fffff800`01c4d733 nt!NtQuerySystemInformation+0x11aa fffff980`113dcc20 00000000`770d05da nt!KiSystemServiceCopyEnd+0x13 00000000`0222e898 00000000`00000000 0x770d05da That last address - that looks like a 32bit kernel address. I've actually seen this exact stack before, and this is almost always something talking to the kernel via a driver running in the Windows User-Mode driver framework service (a svchost.exe process). I've only ever seen this actually be one of two things - one, nvidia chipset drivers, and two, bad memory. First, a note - I am going to assume that you are NOT overclocking your components. If you are, STOP and retest, as overclocked components can cause this exact callstack and bugcheck, so that needs to be ruled out. Again, assuming you are NOT overclocking, read on for some analysis. I can't see exactly what hardware you're using other than the motherboard bios and chipset (the bulk of the global object list is not included in a minidump), but I don't see any nVidia hardware on the P5E board. So, if you're using an nVidia video card, make sure you're using the very latest *windows certified* drivers from nVidia. If you are, or aren't using nVidia hardware at all, run a memory check post-haste. The reason I say this is because Windows is searching actual RAM for some information in an address that the driver requested, and it didn't find it. Since this generated a page fault, and you cannot page fault at this high an IRQL (we're at something higher than IRQL 2), the OS in fact WILL bugcheck. So, either you have a driver that isn't keeping track of it's memory addresses (not probable, but it's at least remotely possible) or you have corrupt locations in RAM itself (unfortunately, in these cases this is FAR more likely). I'd suggest downloading memtest86+ and testing the memory in your machine before doing anything further.

Sounds like a poorly coded and outdated app. Anyways, there's tons of OSS for ISO creating/burning that are coded without using any "native" resources on windows.Or, it could be called being an efficient developer and needing to write fewer lines of code by using the native OS APIs to achieve something, rather than reinventing the wheel by writing your own cd writer driver stack (and going through the hassle of getting it signed for x64 support). Just because someone uses the Windows APIs doesn't make it poorly coded (at all...).

You could use a command like netdom to rejoin, but you can't keep it through sysprep.