cluberti

It is, but technically you should leave it registered but disable it via the CLSID's in the registry. This DLL has uses outside of IE as well, the CLSID is only for the activex control portion of this .dll. Renaming it would technically break any other apps that use it, whereas setting the CLSIDs in the article to "killbit" them will only disable it's use in IE. Actually, Windows Media Center and DX9 make use of it, but only if you write software designed to use this COM object. I don't know of any (legitimate) web sites using this for video content. Everyone uses the WMP control, flash, or silverlight at this point. Yes, although it can be installed by other software. Blindly trusting a file to report the correct extension for it's type is more insecure. Also, checking the type as well as the extension seems like more security, rather than less. In addition, this can be used to verify that the MIME type and the file's contents actually match, rather than blindly trusting the extension and then passing it off to the handler or opening in IE. It's a bit of a security vs usability compromise, and assuming the file type, MIME type, and extension match, why the fuss, really? Lastly, it wasn't intended as a security boundary anyway, it was intended so that bad web devs or web server admins sending the wrong MIME type or extension for a file don't cause IE to fail to open it if it understands the content - that was the real intention, from what I understand. This setting was introduced in IE6, but only on XPSP2 (IE6 on W2K and previous platforms only goes up to SP1) and higher. If you're running Win9x, you do not have this option, and IE uses the file type and MIME type passed only.

Well, thank dencorso for accepting our invitation . We expect he'll be a good addition here, as he's shown the ability to handle such a role both technically and otherwise. Congrats to dencorso, for sure!

Darn - you did say this was XP SP2, didn't you. Pool tagging isn't enabled by default (as the error said) until Server 2003 or higher, so you'll need to enable pool tagging and get another dump. To enable pool tagging, first you need to download and install the current release of the debugging tools for windows, then go to the directory (usually C:\Program Files\Debugging Tools for Windows (might have an x86 at the end of the folder name) and run gflags.exe. Once it's open, check this box, then reboot: Once you reboot, get another dump - we'll be able to tell you what's consuming Nonpaged Pool from a dump with this flag enabled.

I'm not sure if this dump is going to give us much info, as it's a minidump. It's only going to have information (basic) about the currently executing thread (in csrss.exe) and the registers, the memory information is not here. Would it be possible to get a full (complete) memory dump?

NonPagedPool Usage: 65534 ( 262136 Kb) NonPagedPool Max: 65536 ( 262144 Kb) ********** Excessive NonPaged Pool Usage *****Well, that is pretty bad. I'm not surprised your box crashed, considering how fragmented your NPP likely is (on top of being almost completely used). Can you put the .dmp file up (zipped or RAR'ed) somewhere we can get to it?

So the problem isn't SQL, it seems to be the front-end app you're using? Might want to engage the vendor and do some perf monitoring on the machine(s) running the front-end to see what's going on. However, you probably want to have some data from a machine running the old software as a baseline to see differences though, and if the vendor requires the new software I'm not sure how feasible that is.

Another question - is this a single-instance SQL server, or do you have multiple instances? If you've got multiple instances, perhaps Windows clustering (active/active) with instances on separate nodes might be better. If you've got a single-instance server, load balancing will make no difference in performance at all, as SQL rarely causes network saturation (and with 50 - 100 users on a Gb network, that is highly unlikely to be a problem). Usually SQL problems crop up as memory pressure or disk bottlenecks, not network issues (hence moving instances to cluster nodes to alleviate memory pressure and disk bottleneck issues).

To chime in, I've preferred WPF to WinForms for about a year now, and I think I'm more productive with WPF in VS2008 than I was with WinForms in VS2003 or 2005. Second, it would be really interesting if you could configure Seven Update to read reg keys that are set by group policy (similar to Windows Update) so admins *really* have automated control over it. That would be awesome .

The activex portion of the Microsoft Video Control was written at the time to stream video in the browser via said activex control, but around the same time other controls (like flash and quicktime) took the market and the Microsoft Video control went largely unused for this purpose. Unless you have software which uses it (and most IP web-cams I've seen use a java-based control or flash to display the video), you should remain unaffected by doing something like unregistering the control. Note that this *is* used by some TV capture/display boards and media center-type software (including Windows Media Center on XP, although that won't matter to most folks here), which is why Microsoft recommends disabling just the ActiveX COM CLSID, rather than disabling it entirely. This will cause it to still be useful locally to applications, but it will stop working from the browser.

True, but everything in x64 is a fastcall, and there are double the CPU registers. It tends to negate the perf hit for TLB translation in the end, especially for native Windows binaries. And again, there's the added benefit of 4GB of VA available in WOW64 for 32bit apps compiled aware, as well, although I don't know many desktop apps other than graphics programs that do this.

Correct, Windows does the translation. However, there's still a perf hit for the translation and the TLB shoot down. The app just isn't aware of it.

The control won't be IE-version dependant (it's technically not a flaw in ActiveX, but this specific control, so any browser, including IE on Win9x, could be vulnerable to loading it and being affected), and since the Video control was something shipped for Win98, you'd actually be more likely to have it than folks using, say, Windows XP or newer. So, yes, you could be vulnerable and should act accordingly.

I set this up this way on transient networks as well (usually wireless subnets), and it seems to work quite well in keeping the number of IPs "used" down to a minimum.

Might want to just get a perfwiz setup to monitor for awhile, then save the .blg off somewhere we can have a go at it.

That's pretty odd, although not impossible. Hopefully it'll be better with the Win7 WAIK and sysprep, but I personally have not used CopyProfile so I can't comment if that's normal or not. I used a default ntuser.dat and some vbscripts in my unattend after MDT installs the OS to modify the default user profile, which works 100% of the time .

I would indeed say using procmon while running regsvr32 against your .dll would be a good idea. 80040005 is access denied, and procmon would likely show why.

LOL - it involvs inserting the real OS install disc (not a recovery CD, but the actual Windows install disc) into the drive, rebooting, and doing a clean install. AKA, "flattening the drive" in parlance.

Log into a server where the setting is disabled, and run rsop.msc to see what policies are being applied, and from where. If it's not a group policy, you'll probably have to use process monitor with a filter to watch that specific reg key to see who or what is overwriting it with the "bad" value (you can set it read only and remove everyone but your account's permission to the key holding the value as well, so that procmon catches an access denied rather than an overwrite - you catch the culprit, and the value doesn't get overwritten.

Vista has probably earned the distinction of "worst OEM OS loads of an OS ever" with all the horrid drivers and crapware, and god-awful design decisions chosen. I also have a few OEM machines running Vista, but I am glad they were Dell machines and came with a real OS install disc. I've found Vista to be quite fine, but they were all wiped and reinstalled (I tried the OS that shipped, and on all 3, it was awful - reinstall clean with latest drivers, works great... go figure!?).

First, licenses from Technet and MSDN are for non-production and non-personal machine usage - MSDN licenses are for code and dev testing of your code on Microsoft's products, and Technet subscriptions are for evaluation of software in a non-Production, non-Personal environment (there's also a Volume License Administrator version, but that's more an add-on to a volume license agreement than a true Technet subscription). Meaning, if you're planning on buying a subscription to get the software for personal use on your machines, you've violated the EULA that you will have to agree to for either to get the software. Second, you can run MSDN or Technet software on YOUR machines only, and ONLY FOR EVALUATION PURPOSES, not for everyday use, and NOT on any machines that are not going to be actively used by you (aka your friends' machines), that is also in violation of the technet or MSDN EULA that you'll have to agree to when you sign up for and purchase the service - again, I omit the Volume License Administrator Technet subscription, as it's not relevant to your situation (you'd already have to have a volume license software agreement with MS, which would have already obviated your need for a technet subscription to answer your questions). Software from an MSDN or Technet subscription have both the software EULA to consider, but also the limitations on top of the software EULA that are put forth in the subscription EULA (which, again, will forbid personal, non-test/non-development usage, and forbid usage of the software and license keys from the sub on any machines, physical or virtual, that are not explicitly under YOUR control and used by YOU directly. You really, REALLY need to understand what "Evaluate" and "only" mean, and what the statement "only the licensed subscriber may use the included products" mean to truly understand the EULA. If what you think is possible with a Technet plus subscription was actually possible, why would Microsoft sell any product at all when you could get around it for $350 a year? Also, directly from the Technet "compare" page, the answer to your question(s):

As to your second post, I would love to hear the source for that - seems a bit silly. Anyway, if you just want XP, flatten the OS drive and boot from XP install media to get rid of Vista, that works.

While Geoff Chappell's page (that you linked to) is technically accurate on what he discusses, he still fails to mention that you cannot (at least on Windows via the Win32 API) run an executable code block with an address above the 32bit boundary, because the 32bit CPU's registers won't be able to store an address that maps that high. PAE still limits you to a 4GB window, no matter where you slice it, although you can place it higher (above the 4GB boundary, for instance), to load a 32bit app's 2 or 3GB of VA (and the 2 or 1GB kernel VA) into that range when it's loaded. It's overhead for the OS (although probably not much, especially with today's processing speed and multi-core setups), and one that Microsoft only plans to support (or, to be more accurate, planned, as Server 2008 R2 is x64 only, and Win7 will very likely be the last x86 client) on server-class OSes. The RAMDisk drivers that get discussed, while good and useful, still suffer some drawbacks being PSE-36, namely things like all I/O doing double-buffering, or not being able to "slide" the 4GB mapped window like you can with PAE and AWE. Also, with PAE, you've got some issues with overhead in the memory manager itself when you do interprocess communication, TLB reloads on context switching - and a bit more for this on multi-CPU systems, as the TLB buffers have to be synched to make sure they're all accurate in their virtual to physical TLB mappings (although Windows APIs do allow batching of this by an application to try and reduce the perf hit this will cause), you're storing more information in the session view space in kernel for PTE space, even though the kernel is still the same size with or without PTE, so there can be kernel pool and session space cramping on large memory systems in 32bit, and there are more that are documented on technet and MSDN if you want to read up. Or, you could use an x64 OS and not have any of the overhead or restrictions of the Windows platform with regards to PAE and run everything natively (or in WOW64 isolation for a 32bit app, of course - with the side benefit that any 32bit app compiled LARGEADDRESSAWARE actually can use 4GB of VA instead of 3GB because there's no kernel space in the 32bit VA in WOW64). This is obviously easier for developers to handle, and there are other benefits above and beyond that x64 gives but that's outside the scope of this discussion. Ultimately, does it matter? I dunno, I don't think most folks use more than 4GB anyway, and those of us that do are using x64 for reasons other than native support for more than 4GB memory. I still see it as the bridge Intel initially designed PAE (and PSE) for to allow for use of >4GB of RAM on x86 systems before they had their 64bit platform (Itanium) ready.

The caveats are there - one, Win7 must be on both hosts (or the remote host must be a DLNA music player or extender, like the xbox 360 or a MCE extender), and 2, both hosts *must* be running WMP actively at the time. Hence why it doesn't show up in your list, you probably have no valid endpoints that WMP found as valid DLNA devices (or your firewall blocked the scan, or both).

You can enable further ASP logging in the web.config file on the IIS server for the site: http://msdn.microsoft.com/en-us/library/y123fsf7(VS.71).aspx

The issue has come up recently, and is being considered already.