From: benn on
I'm trying to transition from a traditional hard drive to an ssd.
So imaging the working drive in use onto a file, and then placing
that
image file onto an ssd drive.
The problem is that when the ssd drive boots, just after the familiar
windows xp sound comes on, I get a message that says windows has
crashed, and if I wish to send a data dump to microsoft:
svchost szappver 5.1.2600.5512 ntdll.dll szmodver 5.1.2600.5755
offset 100b.
After this, the system just hangs.
Looking at the dump files it created (appcompat.txt*,
svchost.exe.mdmp) they were placed on the E drive!! (which is the
old
hard drive that was the source of the image, to which the ssd booting
should have no dependency on)!
If I disconnect the original hard drive, and boot with only the ssd
attached, it hangs even before the windows xp sound!! If I
disconnect the ssd drive, and boot from original hard drive,
everything works fine.
This leads me to believe that something in the ssd's windows install
(and on the image file) is pointing elsewhere for critical files
that
for some reason it doesn't have. Or, perhaps, since both drives
have identical contents, windows is getting confused as to the active
drive?
How can I troubleshoot why svchost is crashing at startup on the new
ssd drive that's been imaged with a known good os?
*<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="SYSTEM INFO" FILTER="GRABMI_FILTER_SYSTEM">
<MATCHING_FILE NAME="advapi32.dll" SIZE="617472"
CHECKSUM="0xA0887D0D" BIN_FILE_VERSION="5.1.2600.5755"
BIN_PRODUCT_VERSION="5.1.2600.5755" PRODUCT_VERSION="5.1.2600.5755"
FILE_DESCRIPTION="Advanced Windows 32 Base API"
COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft®
Windows®
Operating System" FILE_VERSION="5.1.2600.5755 (xpsp_sp3_gdr.
090206-1234)" ORIGINAL_FILENAME="advapi32.dll"
INTERNAL_NAME="advapi32.dll" LEGAL_COPYRIGHT="© Microsoft
Corporation.
All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0xA5BB8" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.5755"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5755" LINK_DATE="02/09/2009
12:10:48" UPTO_LINK_DATE="02/09/2009 12:10:48" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="gdi32.dll" SIZE="286720"
CHECKSUM="0x98314A3F" BIN_FILE_VERSION="5.1.2600.5698"
BIN_PRODUCT_VERSION="5.1.2600.5698" PRODUCT_VERSION="5.1.2600.5698"
FILE_DESCRIPTION="GDI Client DLL" COMPANY_NAME="Microsoft
Corporation"
PRODUCT_NAME="Microsoft® Windows® Operating System"
FILE_VERSION="5.1.2600.5698 (xpsp_sp3_gdr.081022-1932)"
ORIGINAL_FILENAME="gdi32" INTERNAL_NAME="gdi32" LEGAL_COPYRIGHT="©
Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x4CE95" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.5698"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5698" LINK_DATE="10/23/2008
12:36:14" UPTO_LINK_DATE="10/23/2008 12:36:14" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="kernel32.dll" SIZE="989696"
CHECKSUM="0x2D998938" BIN_FILE_VERSION="5.1.2600.5781"
BIN_PRODUCT_VERSION="5.1.2600.5781" PRODUCT_VERSION="5.1.2600.5781"
FILE_DESCRIPTION="Windows NT BASE API Client DLL"
COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft®
Windows®
Operating System" FILE_VERSION="5.1.2600.5781 (xpsp_sp3_gdr.
090321-1317)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32"
LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved."
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFE572"
LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5781"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5781" LINK_DATE="03/21/2009
14:06:58" UPTO_LINK_DATE="03/21/2009 14:06:58" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="ntdll.dll" SIZE="714752"
CHECKSUM="0xC695BA95" BIN_FILE_VERSION="5.1.2600.5755"
BIN_PRODUCT_VERSION="5.1.2600.5755" PRODUCT_VERSION="5.1.2600.5755"
FILE_DESCRIPTION="NT Layer DLL" COMPANY_NAME="Microsoft Corporation"
PRODUCT_NAME="Microsoft® Windows® Operating System"
FILE_VERSION="5.1.2600.5755 (xpsp_sp3_gdr.090206-1234)"
ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll"
LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved."
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xBC674"
LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5755"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5755" LINK_DATE="02/09/2009
12:10:48" UPTO_LINK_DATE="02/09/2009 12:10:48" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="ole32.dll" SIZE="1287168"
CHECKSUM="0xB764FEEA" BIN_FILE_VERSION="5.1.2600.5512"
BIN_PRODUCT_VERSION="5.1.2600.5512" PRODUCT_VERSION="5.1.2600.5512"
FILE_DESCRIPTION="Microsoft OLE for Windows" COMPANY_NAME="Microsoft
Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System"
FILE_VERSION="5.1.2600.5512 (xpsp.080413-2108)"
ORIGINAL_FILENAME="OLE32.DLL" INTERNAL_NAME="OLE32.DLL"
LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved."
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x14744B"
LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.5512"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5512" LINK_DATE="04/14/2008
00:10:57" UPTO_LINK_DATE="04/14/2008 00:10:57" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="oleaut32.dll" SIZE="551936"
CHECKSUM="0xE8E0E87" BIN_FILE_VERSION="5.1.2600.5512"
BIN_PRODUCT_VERSION="5.1.2600.5512" PRODUCT_VERSION="5.1.2600.5512"
COMPANY_NAME="Microsoft Corporation" FILE_VERSION="5.1.2600.5512"
INTERNAL_NAME="OLEAUT32.DLL" LEGAL_COPYRIGHT="Copyright © Microsoft
Corp. 1993-2001." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0x8D4E3" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.5512"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5512" LINK_DATE="04/14/2008
00:10:58" UPTO_LINK_DATE="04/14/2008 00:10:58" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="shell32.dll" SIZE="8461312"
CHECKSUM="0x229B7DE8" BIN_FILE_VERSION="6.0.2900.5622"
BIN_PRODUCT_VERSION="6.0.2900.5622" PRODUCT_VERSION="6.00.2900.5622"
FILE_DESCRIPTION="Windows Shell Common Dll" COMPANY_NAME="Microsoft
Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System"
FILE_VERSION="6.00.2900.5622 (xpsp_sp3_gdr.080617-1319)"
ORIGINAL_FILENAME="SHELL32.DLL" INTERNAL_NAME="SHELL32"
LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved."
VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004"
VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x812125"
LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="6.0.2900.5622"
UPTO_BIN_PRODUCT_VERSION="6.0.2900.5622" LINK_DATE="06/17/2008
19:02:17" UPTO_LINK_DATE="06/17/2008 19:02:17" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="user32.dll" SIZE="578560"
CHECKSUM="0x6280E825" BIN_FILE_VERSION="5.1.2600.5512"
BIN_PRODUCT_VERSION="5.1.2600.5512" PRODUCT_VERSION="5.1.2600.5512"
FILE_DESCRIPTION="Windows XP USER API Client DLL"
COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft®
Windows®
Operating System" FILE_VERSION="5.1.2600.5512 (xpsp.080413-2105)"
ORIGINAL_FILENAME="user32" INTERNAL_NAME="user32" LEGAL_COPYRIGHT="©
Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0"
VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2"
MODULE_TYPE="WIN32" PE_CHECKSUM="0x8FC76" LINKER_VERSION="0x50001"
UPTO_BIN_FILE_VERSION="5.1.2600.5512"
UPTO_BIN_PRODUCT_VERSION="5.1.2600.5512" LINK_DATE="04/14/2008
00:11:07" UPTO_LINK_DATE="04/14/2008 00:11:07" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="wininet.dll" SIZE="916480"
CHECKSUM="0xCEC12D8E" BIN_FILE_VERSION="8.0.6001.18923"
BIN_PRODUCT_VERSION="8.0.6001.18923"
PRODUCT_VERSION="8.00.6001.18923"
FILE_DESCRIPTION="Internet Extensions for Win32"
COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Windows® Internet
Explorer" FILE_VERSION="8.00.6001.18923 (longhorn_ie8_gdr.
100419-1241)" ORIGINAL_FILENAME="wininet.dll"
INTERNAL_NAME="wininet.dll" LEGAL_COPYRIGHT="© Microsoft Corporation.
All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32"
PE_CHECKSUM="0xE08E2" LINKER_VERSION="0x60000"
UPTO_BIN_FILE_VERSION="8.0.6001.18923"
UPTO_BIN_PRODUCT_VERSION="8.0.6001.18923" LINK_DATE="05/06/2010
10:41:52" UPTO_LINK_DATE="05/06/2010 10:41:52" VER_LANGUAGE="English
(United States) [0x409]" />
<MATCHING_FILE NAME="winsock.dll" SIZE="2864"
CHECKSUM="0x73AE8088" BIN_FILE_VERSION="3.10.0.103"
BIN_PRODUCT_VERSION="3.10.0.103" PRODUCT_VERSION="3.10"
FILE_DESCRIPTION="Windows Socket 16-Bit DLL" COMPANY_NAME="Microsoft
Corporation" PRODUCT_NAME="Microsoft® Windows(TM) Operating System"
FILE_VERSION="3.10" ORIGINAL_FILENAME="WINSOCK.DLL"
INTERNAL_NAME="WINSOCK" LEGAL_COPYRIGHT="Copyright © Microsoft Corp.
1981-1996" VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x10001"
VERFILETYPE="0x2" MODULE_TYPE="WIN16" S16BIT_DESCRIPTION="BSD Socket
API for Windows" S16BIT_MODULE_NAME="WINSOCK"
UPTO_BIN_FILE_VERSION="3.10.0.103"
UPTO_BIN_PRODUCT_VERSION="3.10.0.103" VER_LANGUAGE="English (United
States) [0x409]" />
</EXE>
</DATABASE>
From: Paul on
benn wrote:
> I'm trying to transition from a traditional hard drive to an ssd.
> So imaging the working drive in use onto a file, and then placing
> that
> image file onto an ssd drive.
> The problem is that when the ssd drive boots, just after the familiar
> windows xp sound comes on, I get a message that says windows has
> crashed, and if I wish to send a data dump to microsoft:
> svchost szappver 5.1.2600.5512 ntdll.dll szmodver 5.1.2600.5755
> offset 100b.
> After this, the system just hangs.
> Looking at the dump files it created (appcompat.txt*,
> svchost.exe.mdmp) they were placed on the E drive!! (which is the
> old
> hard drive that was the source of the image, to which the ssd booting
> should have no dependency on)!
> If I disconnect the original hard drive, and boot with only the ssd
> attached, it hangs even before the windows xp sound!! If I
> disconnect the ssd drive, and boot from original hard drive,
> everything works fine.
> This leads me to believe that something in the ssd's windows install
> (and on the image file) is pointing elsewhere for critical files
> that
> for some reason it doesn't have. Or, perhaps, since both drives
> have identical contents, windows is getting confused as to the active
> drive?
> How can I troubleshoot why svchost is crashing at startup on the new
> ssd drive that's been imaged with a known good os?

When you "clone" a bootable C: partition, to a second storage
device, you're supposed to *unplug* the original drive,
for the very first booting of the clone. Once you've booted the
clone, all by itself, you shut down the computer again, then
connect up the old drive. Doing so, will avoid complications.
You can boot as many times as you want, with both drives
present, after booting at least once with the SSD by itself.

To fix it, reclone your SSD (copy the info over again). Shut
down the computer and disconnect the original drive. Reboot with the
SSD clone in place. After that, it should be clear sailing.

And I presume you already had a driver in place, for the
SATA port the SSD is using ? I suppose that has to be the
case, as otherwise you'd have had a problem using the SSD.

There are various techniques for optimizing operation of Windows
on an SSD. In some cases, this involves placing only one
partition on the SSD (C:), and starting it at an unusual offset
from zero. The purpose of that, is to better align the natural
128KB block size of the SSD, with the partition you've just
put in place. This causes all manner of issues (many disk utilities
don't like it and will throw up warning dialog boxes), and
is something you may want to research a bit. You can always
continue on with what you're doing, but some of these "polishing"
techniques can squeeze a bit more of the performance
promised by your SSD.

This forum is a good place to start. I don't actively keep track
of the latest techniques in SSD polishing, so you'll have to
look around, to get some idea if this is the best way to
do things or not. If I could ever afford an SSD, I'd have
to go through the same series of experiments you are,
to find the best way to set it up, and I'd be looking forward
to hours of reading these kind of threads.

http://www.ocztechnologyforum.com/forum/showthread.php?48309-Partition-alignment-importance-under-Windows-XP-(32-bit-and-64-bit)..why-it-helps-with-stuttering-and-increases-drive-working-life.

Paul
From: John McGaw on
On 7/25/2010 9:29 PM, benn wrote:
> I'm trying to transition from a traditional hard drive to an ssd.
> So imaging the working drive in use onto a file, and then placing
> that
> image file onto an ssd drive.
> The problem is that when the ssd drive boots, just after the familiar
> windows xp sound comes on, I get a message that says windows has
whole buncha' stuff snipped...

What software are you using to clone the drive? Have you used this software
before with success? Why are you going through an intermediary file in the
process? Did you disconnect the old boot drive before trying to boot from
the SSD? What other drives, if any, are present on the system? Does the MB
support SATA natively or does it require drivers to be loaded? BIOS boot
device and sequence taken into account?

I would suggest that you try cloning direct drive-to-drive and then
disconnect all other drives on the system before attempting to boot from
the SSD. I've never had a cloning fail if the proper software and steps
were taken and SSD vs. rotating should make no difference to the BIOS.


From: ElJerid on
I had exactly the same problem when I used Acronis True Image or Norton
Ghost to create the new partition on the SSD.
Then I tried XXClone (free):
http://www.xxclone.com
Simple to use and worked perfectly !
Hope this helps also for you.


"benn" <benn686(a)hotmail.com> wrote in message
news:37824996-d88c-4c51-9373-bdd9a7ef5a5b(a)p11g2000prf.googlegroups.com...
> I'm trying to transition from a traditional hard drive to an ssd.
> So imaging the working drive in use onto a file, and then placing
> that
> image file onto an ssd drive.
> The problem is that when the ssd drive boots, just after the familiar
> windows xp sound comes on, I get a message that says windows has
> crashed, and if I wish to send a data dump to microsoft:
> svchost szappver 5.1.2600.5512 ntdll.dll szmodver 5.1.2600.5755
> offset 100b.
> After this, the system just hangs.
> Looking at the dump files it created (appcompat.txt*,
> svchost.exe.mdmp) they were placed on the E drive!! (which is the
> old
> hard drive that was the source of the image, to which the ssd booting
> should have no dependency on)!
> If I disconnect the original hard drive, and boot with only the ssd
> attached, it hangs even before the windows xp sound!! If I
> disconnect the ssd drive, and boot from original hard drive,
> everything works fine.
> This leads me to believe that something in the ssd's windows install
> (and on the image file) is pointing elsewhere for critical files
> that
> for some reason it doesn't have. Or, perhaps, since both drives
> have identical contents, windows is getting confused as to the active
> drive?
> How can I troubleshoot why svchost is crashing at startup on the new
> ssd drive that's been imaged with a known good os?