Jump to content

cluberti

Patron
  • Posts

    11,045
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    country-ZZ

2 Followers

About cluberti

  • Birthday June 27

Contact Methods

  • Website URL
    http://www.cluberti.com

Profile Information

  • OS
    Windows 10 x64

Recent Profile Visitors

11,187 profile views

cluberti's Achievements

8

Reputation

  1. Dropped you a PM :) Please respond. Thanks. 

  2. It's always been possible with Azure VMs. You'd set up a vNet and then create VMs and configure it on those VMs as you would anywhere else. The tricky part is if you wanted to extend it on-prem, you'd need to configure ExpressRoute and some other things locally, but if everything will live in Azure, it's entirely possible.
  3. Same thing in the new trace - see my last post for options.
  4. I've edited my post above after digging deeper - I'd wager IRQ sharing is the root cause under load. Since you aren't likely to be able to move your chipset controller as it's soldered to the board, you might want to try moving your video card to different PCI-E slots to see if it can be moved to a different IRQ. If not, you might want to try a different card altogether if possible to make sure it's not caused by a failure of the video card itself (I've seen this behavior happen before for that reason, for what it's worth).
  5. If that's the case (those listed routines call HDAUDIO functions, which would call the audio driver), then you have to start looking at both your video card drivers and your Intel ICH/RAID drivers. Both also have a decent number of interrupts as you can see in the table above. I noticed that the Intel Chipset is listed on IRQL16, as is your video card. Not good.
  6. I'll try to take a look at this in-depth later, but it appears your audio driver is a very likely culprit, CMUDAXP.SYS:
  7. No, that call is doing exactly what you think it is. I think you're right given the data.
  8. I searched the DB and there's no record of that username, or email address, ever being registered.
  9. The question is, why is the system paging things to the paging file that would cause a slowdown with that much RAM? The paging file might hold old pages on the modified list or standby list, perhaps, but only if the system was busy or the app was minimized and idle for an extended period of time on Windows 7. Also, why would it be the cause of your performance issues? Those would be the issues to investigate/address, although with 16GB of RAM a 2GB paging file and a system set to kernel memory dump should be sufficient under normal usage scenarios. You probably need to determine if your HDD thrashing really is paging file usage - don't just assume.
  10. Most browsers keep a DNS cache separately from the OS cache, and while I don't have specific documentation for other browsers, Microsoft talks about IE and DNS here: http://support.microsoft.com/kb/263558
  11. Clearing the cache also clears the DNS cache - if it magically fixes things, it actually does give the tech a clue about what's wrong. I may be being overly optimistic in believing the tech knows this, but it is in fact true.
  12. Well, it's always your machine - do with it what you will. As long as you know you're doing something purely for OCD reasons and you know the risks - it's your machine! If you want to clean the registry, do it. Just know that it doesn't really do anything measurable , and there can be risks involved. At the end of the day, though, you have to do what you have to do, even if it just scratches an itch in your brain.
  13. Given registry access is done in memory and whole hives are not necessarily automatically loaded anymore, MagicAndre is correct - unless the registry hive is gigantic (1+GB, and even that doesn't take much on a newish system) and horrendously fragmented on disk ... and it's not an SSD), loading the portions needed into memory don't take very long at all during boot (perhaps a second or three). Also, given the hive as a whole is no longer loaded in it's entirety, "cleaning" it or compacting to clear white space is only going to give you back some MB on disk - it isn't likely to improve performance in a perceptible way at all unless the system is *really* old with a *really* slow 5400RPM or slower disk as the boot volume. In my experience, only then would "cleaning" the registry provide performance gains. Having duplicate entries in places could cause *application issues* if the app itself doesn't like such problems, but those are application stability issues, and it won't make Windows (or the apps running on it) go any faster in any perceptible manner. As MagicAndre said, this has been this way since XP in 2001, and even Windows 2000 did a better job of 9x loading hives into memory so it wasn't really an issue there either. This is one of those nuggets of "legacy knowledge" that keep getting trotted out as a help when, in fact, it's at the least fairly useless, and potentially dangerous to system stability (I've seen registry "cleaners" totally break boxes), with no real upside that would be gained by doing so.
  14. It appears there are potentially still some issues with the hoster's MySQL servers hosting the MSFN database, but xper is working on it. We apologize for what's happening, and are working on resolving things as quickly as possible.
×
×
  • Create New...