cluberti

Srr.exe is likely from an app called "ReScene", which allows for unpacking .rar files split across multiple chunks into a resultant file, without touching the .rar files themselves. This utility tends to be used mostly in the warez scene, but I've seen a few malware packagers use it as an extracting mechanism for "updates" released over time (slowly download .rar files split into small segments so the user doesn't notice the bandwidth hit, and then unpack and run the resulting payload once all the chunks are down). Sounds like you had some malware or a virus at one point, and it's no longer on the machine but there's a startup entry for that tool. I would do what the previous poster mentioned - download autoruns and clean out the entry.

Try uploading the .dmp file after placing it in a .zip, .rar, or .7z archive. You can upload that.

It looks like the error is indeed an access violation, and it's happening after BTStackServer.exe finishes loading wdmaud.drv and starts to initialize it. We can see in the procmon it looks through the Image File Execution Options keys, and then abruptly bails - and we can also tell it's likely not a permissions or access error, but perhaps a problem with something in the binary itself based on what it's reading in from the registry. Procmon won't tell us any more than it has, only a crash dump of the .exe failing will tell us more. What I would suggest is downloading and installing the debugging tools for windows, creating a folder called c:\adplus, then opening a command prompt, changing to the directory you installed the Debugging Tools into (usually C:\Program Files\Debugging Tools for Windows (x86)\), and then executing the following command: cscript adplus.vbs -crash -quiet -o c:\adplus -sc C:\Program Files\WIDCOMM\Bluetooth Software\BTStackServer.exe If it succeeds, it should spawn the BTStackServer.exe binary, dump it when it crashes, and create a folder structure inside C:\adplus that contains some .txt files, a .dmp file (at least one, maybe more), and a few other things. If it does, we can look at the contents of that folder for clues as to why it's failing.

Actually, text-mode setup like the one used in XP and 2003 was first seen with NT 3.1, which places it's public appearance back to July 27, 1993. As to the OP, I would suggest copying the Windows 7 media onto a USB key (4GB or larger) formatted for FAT32 or NTFS (NTFS is preferable), and that is made bootable via the bootsect.exe tool. Microsoft makes a tool that can do all of the USB key fiddling for you, here.

If you run process monitor and then double-click the .exe, does the process monitor log show any access denied errors?

Well, we're sure it's the USB host bus - you said you have a USB keyboard and mouse, so I ask which ones and type? Did either of them require drivers for Win7? Short of that, you can try removing the mouse and putting the computer to sleep, and if that doesn't work plug the mouse in and try removing the keyboard before sleep.

Yes, but you must be careful with it. If you capture an XP image to a WIM, it must be \Windows or \Winnt, otherwise it won't deploy properly. Flat-file images work fine, of course, and I prefer those anyway.

There's also the option of using MDT: http://www.cluberti.com/blog/2009/08/10/md...from-a-usb-key/

In windows 7, open an elevated cmd prompt and run "powercfg -lastwake" to see what woke the machine last.

That error code maps to Win32 error CTL_E_PERMISSIONDENIED, so you might want to run process monitor (from sysinternals) while attempting to use msinfo, or run windows update, etc - your permissions somewhere, be it file or registry, aren't allowing your account to do something it needs which is probably simply a residual change that didn't happen during the upgrade. Yet another reason why it is ultimately better to do a clean install .

Since it's XP Pro, you can also run lusrmgr.msc directly.

Aaah, ok. Well, you managed to show proof then that you're using an OEM Dell SLP key, specifically Dell Product key 342DG-6YJR8-X92GV-V7DCV-P4K27 which generates an activation ID of 7cfd4696-69a9-4af7-af36-ff3d12b6b6c8, which was leaked a little over 2 months ago. I can tell this simply from your screenshot and knowing that activation ID will only exist for machines using that specific Dell OEM key, which means to achieve a "licensed" status on a non-Dell machine with a Dell key and activation ID, you *have* to be using a cracking tool like Windows 7 Loader or similar, aka using the "paradox crack". As such, this is asking questions about problems with pirated software, in violation of the very first rule of the forums: Consider yourself banned. [banned].

If you follow the instructions in the KB article linked and do it manually, it won't matter what the driver was set to. Disabling the interfaces at the OS level will mean the driver will start up, query support, and won't enable those functionalities once loaded if the OS says "no".

No, there's no workaround. The Win7 and Vista setup routine cannot bootstrap a WIM file that contains anything but Vista or Win7 (or Server 2008 / 2008 R2, of course). What happens is PE boots, you choose the image, and then setup.exe runs to prepare the WIM for extraction, and it requires the WIM to be a Vista or Win7 image. XP WIMs will just hang for awhile, and then complain about the image being invalid or not found. If you want to deploy XP from a WIM, you'll have to make your own custom WinPE (or use something like MDT 2010) to deploy the WIM with imagex.

Is that a Dell computer, by chance? If not, let us know.

Moving from WUD to nLite.

Welcome to the forums, Tobias. I need you to make sure you've read the rules here, because your question pretty much falls afoul of rule 2.c: Your questions are innocuous, but you'll learn more if you try for yourself and determine if you can or cannot do these things. The project and your education should be yours, not MSFN's to help with. I am sorry, but these rules are in place to help people who are doing things for their education, not to hinder you.

...until it happens twice. Then, might as well fix it and find root cause, otherwise it'll just keep re-appearing.

Problem for those of us running Vista or Win7 though - disabling the driver check just to run an app isn't very friendly. Very cool looking app otherwise, though.

No worries. Welcome to THE forum .

If disabling offloading causes a bugcheck, you've definitely got driver problems. Those are classic TCP chimney behaviors, honestly.

Usually all that's left is a log - it's probably meant to be hidden and removed after install, but isn't (for whatever reason). These are safe to delete, fwiw, but as to why it's left behind it would probably be specific to the update (usually msxml updates are the worst offenders, for example).

For a master image, what I would suggest is this: Boot the Win7 installation media on the template PC (or virtual machine) Use the disk management in the installer itself to delete ALL partitions Create a new partition and format it NTFS, again using the disk management tool of the Win7 installer Select that partition to install Windows 7 into; Windows 7 will install to this partition Configure Win7 after installation Once finished configuring, shut down the PC and take an image This will result in your image having ONE partition, and not the second 100MB partition for EFI and bitlocker. Since you don't actually necessarily need this unless you're going to be booting EFI machines (bitlocker will create it's own partition for conversion when it's first run to bitlocker a drive, so this is only a convenience for speed in that case), you can create an image without it.

That is correct. When it gets set to be applied, it runs through the filter and tries to find the COMPUTER object. Since it never finds one that matches, it isn't applied.

You could consider removing it in the .WIM file and image itself offline, so that the feature isn't enabled at all during setup: http://technet.microsoft.com/en-us/library...506(WS.10).aspx