cluberti

http://arstechnica.com/news.ars/post/20071...ttling-p2p.html Take a network trace - you're liable to see lots and lots of random RSTs coming from devices (not on your network) in the trace on the port(s) that your P2P app is using, forcing it to slow down, start over, etc. That's all there is to it.

I used /quiet /nobackup /forcerestart

If you're talking about 2 machines transferring on a 100Mb network, the max you'd get between the two is 12.5MB (25MB if it's full duplex, theoretically). However, assuming you're using the TCP/IP protocol (default in Windows), and even if your network runs at 100% efficiency, for each Mb of speed you'll see anywhere from 20Kb to upwards of 128Kb TCP overhead depending on the network config and potential changes / tweaks that are (or are not) on your machine. At 100Mb/sec, you should expect on a well maintained, good network to see upwards of 4-12Mb/sec of that be simple TCP overhead depending on the machines and network equipment at each end. And those of us who have done this for a living know that those are good numbers, and normal operations sees higher overheads due to other issues as well - seeing over 10MB/sec transfer on a 100Mb network means you're getting great transfer speeds (of course gigabit networks will provide much faster throughput, but you will also see more frame and TCP overhead...).

No, not noticeably. It's just copper wire, shielded. It's nothing special - if you've already got CAT3 in place, replacing with CAT5 won't get you any benefits other than a CAT5 run can bring 4 separate lines down in one cable run.

And CAT5 can provide you 4 phone lines per cable run (only two wires needed for phone line, CAT5 has 4 pairs). I do this all the time.

The next question - does it crash immediately on startup, or does it run for awhile and then crash? I'm assuming the former, but I want to be sure first.

Well, technically a user can try to do something that would require admin access (like open regedit), but I believe that should give them a basic UAC prompt asking for a username and password from an admin user account. I'm not sure they aren't supposed to get NO prompts, but that could be what you're attempting to do. If you create a shortcut to regedit.exe on the desktop and then right-click "run as administrator" as a normal user, do you get any prompt?

Please try to post in the appropriate forum. *moved*

Yeah, with the /PAE switch in boot.ini. However, if the BIOS reserves memory BEFORE the operating system boots, it won't be visible or available to the OS no matter what.

If that's the case, something's broken... What version of Vista is this, and did you use vLite on it at all?

What about doing it manually? Not sure how to do it manually I've found using it in runonce (rather than integrating) removes a lot of issues with hotfix detection, because while the binaries in \system32 get updated when it is integrated, I've seen enough systems where the \system32\dllcache binaries are still IE6 and are not updated to not suggest this method to everyone (this problem will cause IE hotfixes to fail to install properly). Instead, run the IE7 installer in runonce and then install the latest cumulative (currently MS08-024), which will do the same thing (basically) without the potential mess.

If you are actually logging in with the local administrator account, UAC is not enabled on that account (it has full access). You need to create a NEW account (preferrably not administrative) to use UAC.

Well, the real question is, after you disable the VS JIT debugger as per the link above, does the app still crash?

You are looking for information on Terminal Services. Note that to install Terminal Services itself, you don't need to actually buy anything more than your Windows licenses. However, to use it, you will need to activate the TS license and client/device CALs for your clients to use.

http://www.msfn.org/board/32bit-Windows-no...RAM-t97580.html It's not a Windows issue, it's a BIOS issue. You're going to be out of luck for 4GB RAM if you need to use x86.

Well, MSI doesn't "just randomly" find a problem and pop-up to fix it, something in the original install is missing and then it tries to "fix" it (the reason old installers don't do this is they lack the functionality to detect when an installed product is no longer matching the installation manifest, but that's another discussion). As to Office, they have some of their own logic to handle this and they do have installation options to place the right files on disk, or just the MSI to do the "detection logic". You can install office without the need for media, but it does place a cache on disk (not done by default for obvious reasons), so if your complaint is mainly around Office MSIs, I feel for you. As to the original post, I still say it's probably better to "fix" the problem that got you into the mix, but if you can't (for whatever reason), then consider the debugger approach if taskkill or pskill do not do the trick.

To play devil's advocate, you deleted the installer (MSI) from the uninstall location, and then tried to uninstall it, and it broke?And your quote about other installers, they are not managed, but install an uninstaller with the product. However, this makes it impossible to centrally manage these without a 3rd party product in an enterprise (like SMS can do) - whereas an MSI can be installed from anywhere and then removed again via policy. It is also a way to allow for a repair of an application that may have broken without having the installation media available, also a nice touch if you, say, have just a laptop with you when some MSI-installed app breaks and you have to repair it. Possible with an MSI-based package because the data to fix it is on the machine, and not possible with other installer types without having the installer somewhere (either elsewhere on the disk, or on installation media you carry with you). It's 6 of one, half-dozen of the other. And having been bit by a broken non-MSI-installed application before without the media with me, I do like having the ability to repair the app without finding or having the media on-hand. I don't want to sound like a jerk, but I am just playing devil's advocate. I don't have all of the "registry" problems or "installer bloat" issues you complain of in my environment, but I'm also pretty on top of things when it comes to installed apps and such. I don't have to support anything truly old either, so maybe that just makes me lucky. But, to be fair, I've not found any real issues with MSI packages that you are complaining of either, so it is possible it is something specific to your environment.

The APIs and imaging subsystem have changed, to a point where vendors writing drivers for 10 year old hardware originally designed for Win9x and *maybe* Win2K cannot honestly be expected to (at their cost) write a Vista driver and still consider it fiscally responsible for the bottom line and for shareholders. True, if cost were no option (i.e. Linux drivers) I'd expect vendors to write drivers ad nauseum, but they're in it to sell hardware or software, and writing (good) drivers takes time, money, and dev cycles better spent on product development. As long as vendors are writing Windows drivers, there will be a cut off point.

Schannel log would probably have showed you the way - good job on the find .

The problem is usually a disk or memory controller that uses 32bit DMA, even under x64 (either incapable of doing 64bit DMA or does not work properly). I have a machine at home with an Intel chipset that does this (it's not the amount of RAM, per se, it's the number of slots filled) - when I have the first two slots filled (even with 2GB+2), everything works fine at 4GB. However, if I put memory in the last two slots (could be 1GB+4, 2GB+4, 512+4, etc), Vista ALWAYS bugchecks.

A JIT debugger prompt like this would only occur if the application you were running ran into an exception. By default in Windows, an attached debugger always gets the first shot at handling an exception, even before the application. Since this could be a first chance exception that the app may be able to handle without user intervention, I would suggest you disable the VS JIT debugger. If the app still crashes, I would suggest a different debugger, like ADPlus.

schannel logging is your best bet. It almost seems as if the cert problem happened during the install to the x64 server's cert store.

Understood - I didn't understand your initial post. XP will be supported, at least for security fixes, until 2014, although I cannot guarantee vendor support for drivers or software to that point .

What kinds of issues are you running into?

Consider simply attaching a debugger (like windbg) to the process, and then forcibly closing the debugger. Any process attached should "die" as well. The real question/problem you face is that your apps are getting into a state where they're hung like this - I think troubleshooting HOW they get into a single thread wait state is probably going to do more for you, long term, than figuring out how to band-aid the problem by killing the apps.