allen2

The dset report should give you more information than the binary of the tool itself. The password protected archive created by dset is protected with the password : dell.

Cmd alone should also close. You might need to run cmd /k if you want to keep the cmd windows open.

If it is for file sharing, there is least ftp but you'll need a tool to properly integrate it in the shell. Old IE (IE 6) and OS (2K,XP at least) could do this using iis ftp and typing ftp://login:password@remoteserver/reltive_ftp_path in an explorer windows would allow to browser the remote as unc path would.

There is something called restricted groups that you can enable through GPO that will most likely do exactly what you want without any need of user interaction.

Perhaps you might begin by : - explaining what is wrong exactly - exactly what you did and how you did it - post the exact model of your mainboard.

This fact is most likely due to at least 4 things: - most developers didn't need the x64 big registers in the first place (they were already using alternate ways) and most companies didn't want to spend money on this transition. - Microsoft and Intel didn't "push" it to the end users as it was done in the past. In the past every new computer was sold with windows 95 without the buyer agreement (that was illegal and there were many law suits). - Compatibility with older apps wasn't fully there and there was a lot of apps (much more than when windows 95 appeared). - There were also a lot less computers. Now computers are everywhere and replacing all of them or only their OS might be very expensive.

The cons: Some x86 might not work as x86 on x64 isn't fully compatible but those are rare exceptions (most of the problematic apps comes from those with drivers that doesn't exist for x64). Some drivers doesn't exist at all and you'll need a VM or equivalent. Some dos apps/games won't work unless run in dosbox. Etc... The pros: Your apps will be able to use natively all ram. You'll get a little longer support (1 year) as Windows 2003 x64 is using the same binaries the hotfixes and security fixes will work on XP x64. You'll begin the transition to x64 that will happen sooner or later.

It "should" work also for any other board based on the same chipset unless they changed the way it install. Most of the time you can still find solution to get drivers working for an officially unsupported OS by using those from another OS. Wifi should be independant. Also the lan drivers for XP taken from either intel or asus (choose the lan driver for windows 7 32bits but anyway the package seems to contains all os) should work on XP. The problem will be the usb 3 drivers as intel doesn't provide usb3 real drivers for XP but only null drivers (so usb3 ports become usb2). As for audio, the realtek drivers (provided by Asus for win7 again the package seems to support all os) should work. So the real problem is most likely, do you want to buy a mainboard and install on it an unsupported OS (for example linux isn't listed as a supported OS but it will most likely work perfectly (intel usb3 is supported under linux)) ?

Hum, intel is still supporting XP with 8 chipset series for its own boards: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3683&DwnldID=23061&ProductFamily=Desktop+Boards&ProductLine=Intel%C2%AE+8+Series+Chipset+Boards&ProductProduct=Intel%C2%AE+Desktop+Board+DB85FL〈=eng

Did, you tried with diskpart ? Also, perhaps, you'll need to remove the existing partitions (be sure to make backups of the data stored there) and recreate a new partition scheme after a clean (it will wipe all from the select drive so be careful) from diskpart.

If you want to have your bios set to localtime then this should help.

Personnaly i would try the ddo approach, i used one (and had to use one again recently for 3TB drive) without any trouble as it should be the easiest to setup and use the full drive capacity. But from what i read, sometime not even a ddo can work and you have to manually edit the drive geometry in the bios and set head to 255 (but that was to use only one drive).

I agree on the order but remember that windows features (like sfc) might be usefull in somecase (of course, most people here don't use it and prefer to even disable it to be able use custom system files). There is an example of a dangerous usage of a linux AV (of course as it is an example, it happens after a human error): - the linux antivirus detect a critical windows boot file as a virus (commonly called false positive) and remove or quarantine it. - your windows won't boot anymore. - In that case a windows antivirus might not have been able to remove it and/or an event should be logged in the eventlog and in the event it would have been removed an sfc /scannow might solve the problem when you get the removal notification. So as usual, if you're knowledgeable enough (and have the time), you don't really need an antivirus (either on linux or on windows). But if you want simple way of protecting your computer, a windows antivirus will be a lot easier to handle. Also, i know very few people that would be able to handle linux and master windows filesystem properly (that isn't a proof or anything in itself).

Obviously, the driver didn't get created by asrock but by AMD so i don't see why it wouldn't work for this MB but works for others.

I never said that. Ntfs-3g is the best choice right now to read/write files on a ntfs partition but i still wouldn't use it for AV scanning. As any malware intend to protect themselves from being cleaned, there is alway a chance that it could mess with the file system and/or any other thing (mbr/boot sector/bios/uefi), so i wouldn't push the luck as to try cleaning it from another OS unless i don't have any other choice. That's all i wanted to say.

As linux kernel doesn't support ntfs r/w by default, there are many different ntfs drivers that works quite fine for most of the tasks but i don't find very clever to mess with an ntfs partition from linux especially to find viruses that might sometime hide in alternate datastream. Taken from lastest kernel source Kconfig file:

Perhaps you should define the border between a script and a program. The real definition of a script is anything that doesn't need to be compiled to run but in my own opinion this isn't a good definition. The right definition should be the complexity of the work, its usage and the time needed to develop it (so of course it would be different for all people). When i create a script with more than 100 lines, i usually doesn't call this a script anymore. Also, you forgot something, the time and the size needed to do the work. In some case, creating a script will be enough as it will do the work fast enough. But in other case, there are no way to avoid creating a compiled program to do the work and then adding some work to the developping process. As everything, it heavily depends on how you master each language but redoing all the work from zero in another language might be a hassle when that happen.

Itanium (ia64) version also exist for windows 2008 and windows 2008R2 but there aren't enough data to add them in the chart.

There is also a strange "mistake": AFAIK there is no x86 Windows 2008 R2 SP1. That's very disappointing from a MS guy.

As this setting is usually set under the settings of the network driver, you might have to edit the network driver so the default settings are set as needed or perhaps only setting the right key and disabling/enabling the driver would be enough.

I also had the problem and it was indeed at least a dns issue (the dns server owning the domain name were down).

So in the end you get an error in the eventlog that is obviously related to the problem even if you don't know what is raidport0 (it most likely the driver of the controller that is reporting this) and from this event and the specs posted on page 2 i'd say that one Seagate Barracuda ST3640323AS or both or the controller is hanging at some point. Maybe upgrading the motherboard raid drivers will help.

You don't need to buy anything, all you need to do to be sure is to able to reproduce the issue or at least know how often it happens then, to rule out the psu without replacing it, you'll have to remove components to reduce the power consumption. On a side note, i suppose you could remove all hdds and odd and check if the problem is stil there, then adding one hdd at a time might help to know which hdd might be the culprit. If the problem never happen with less power load, then that's the power supply that is begging to fail. If the problem happens with every hdd (and only one connected at the same time) but never happens without the hdds then it could be any parts connected but not the hard drives as all drives should have a problem and the same one (and that would against all odds). If the problem happens with only one hdd and never happens without it then this hdd is very suspicious. etc.... Usually, to be sure you need to do cross check but to use this method you need to have a spare for all parts.

The wattmetter report the psu consumption (not what the components ask to the psu on each power rail) and might miss the peaks of power. If you want to be sure, you could run a benchmark or anything cpu and gpu intensive and monitor how the wattmetter react.

Do you overclock either the cpu or the radeon ? That psu could be the root cause as it deliver just enough power for a standard use (i used this psu calculator) and perhaps it now can't deliver enough power for all your components. It could have been damaged or is just too old. To avoid those kind of problems, i usually choose a psu that can deliver at least 20% more.