Ghost Solution Suite

I have two versions of Ghost32 that I have tried using and both do not work. On v11, Ghost will not recognize any HDDs 750 GBs and above. On 11.5, if one of these HDDs are plugged into the computer, it just plain crashes. I've tried several HDDs, most around 750 GBs and 1 TB, on several computers.

I've been looking around, but I can't find much info on this. Is there a size limitation? Is there a newer version of Ghost that will resolve this issue? I can get a PO approved from my company, if that's the case.

Thanks,

Ernest

With the Ghost executables from Ghost Solution Suite 2.0 and 2.5, if a problem occurs then the program will write a diagnostic file called GHOSTERR.TXT with all the technical information about the system on which the problem occurred, which can be of great help in determining the cause of the problem. "It crashed" is rather too vague to be useful, especially given that all versions of Ghost Solution Suite (from v1.0, when the product was renamed from Ghost Enterprise v8 to Ghost Solution Suite 1.0) have been extensively tested on multi-terabyte disks and arrays and thus whatever the cause of your problem it is *not* merely  a capacity issue.

Note that if the Ghost Solution Suite cloning executables fail without generating such a diagnostic file, then there is a procedure for that too, which involves obtaining a snapshot of the process at the time of failure. Again, more information is critical, as outright faults are rare.

Also note that when quoting product version numbers, it's good to include information about of the specific build(s) involved; if you have Ghost Solution Suite 2.0 then there were several LiveUpdate releases, so that the product version should be v2.0.2, and for Ghost Solution Suite 2.5 the most current LiveUpdate release is v2.5.1 released in late 2009 (after which there have only been small patches for minor issues, which are not available without a maintenance agreement per the sticky at the top of the forum - it's unlikely that they will be related to whatever problem you are having).

For what it's worth, I have no problems imaging multi terabyte disks using the Ghost 8.x executable running under WinPE - it can also create a single large GHO file if backing up to NTFS.  As Nigel states, it is very unlikely that your issues relate to the Ghost executables.

However, if you are using DOS as your boot environment, you should be aware that DOS does not support SATA drives, so you may need to switch your bioses to IDE compatibility mode.  As you have tried GSS 2.5 - can you tell us whether you generated a suitable WinPE boot environment with the appropriate SATA drivers integrated via Ghost Boot Wizard, as this is the configuration that is most likely to work with modern hardware.

Hi Friend,

As mentioned by Nigel and Ed, Size is not exactly the reason for the failure. You have mentioned that your HDD crashed. When did this occur ? Was that right at the beginning? Or is it that the ghost transfer was a success but machine failed to boot up ? Please give  more info on your scenario so that we could help you. Also, Please explain how exactly are you imaging your drives.

Regards,

Dilip Sebastian

All,

Thanks for the information. I'll explain a little more about what's happening.. When opening Ghost32 v11.5.1.226, the application fails to load and crashes. The computer nor the HDDs crash. Just the software.

I'm running Ghost off of an external 1 TB HDD, but the issue occurs when just running off my desktop as well. When I have a 750 GB external HDD plugged, is when the issue occurs. If a smaller HDD is plugged in, no problems arise.

As for the error files, none are produced. So how would I obtain a snapshot of the process?

Ghost32 v11.5.1.2226

In other words, you've licensed Ghost Solution Suite 2.5 and have applied all the available LiveUpdates.

the application fails to load and crashes

The problem here is that many of our customers don't know what "crash" means. Even folks on Symantec's QA team for Ghost didn't, and would regularly file "crash bugs" against the software simply because it put up a pop-up dialog explaining something. In the case of the Ghost32 executable specifically, basically *any* error that occurs when the program is actually running generates a GHOSTERR.TXT, and so if there is for example an exception dialog being generated by Windows, that would only happen if it occurs very early during program startup before Ghost sets up its own error handling.

So how would I obtain a snapshot of the process?

This depends somewhat on the circumstances needed to produce the error, and what it is. There are a large number of diagnostic facilities build into Windows itself, although they have changed (not always for the better) from edition to edition.

If the situation can be reproduced by running on Windows XP, then you can use the userdump.exe tool to obtain snapshots of processes under various circumstances, and that tool can be downloaded here. This tool is the most flexible option in terms of allowing you to trigger captures.

If the situation is only reproducible under Vista or Windows 7, then this is now done by configuring Windows Error Reporting through the registry.

To start with, you want a minidump rather than a full dump (full dumps are very, very large and with Ghost32, usually not necessary). These dumps can then be loaded into any normal Windows debugger, such as Debugging Tools for Windows for cursory analysis, and can be sent to the Ghost maintenance team (who have the source code and debug data from the application build process) for more detailed analysis.

It's because of this ability to allow the developers to analyse things against the source code that process dumps are the gold standard for evidence in debugging.

There are other pieces of useful evidence that can be gathered with the help of Debugging Tools for Windows. Most people who work with Windows are familiar with Process Monitor, which is a tool for interactively tracing what programs do. Debugging Tools for Windows includes a less user-friendly but much more detailed trace tool called simply Logger, which can be used to obtain a very detailed trace of the activity of a Windows process.

Since in your case things fail very early in the process, the cause is most likely occurring when Ghost is inquiring what is present in the system, and most usually the cause of a fault at that point would something like a defective Windows driver returning bad data. Using a tool like Logger would generate a detailed trace showing the order that the detailed API calls were executed in, which would then be compared against a working baseline system - by comparing against a known good baseline it's then possible to highlight where the problem-affected system diverges.

Nigel,

I'm not convinced this has anything to do with a specifc OS since it fails on every PC I've tried it on. I tried debugging with logger.exe, and it starts to work, but then the command window freezes when Ghost freezes and logger doesn't continue.

Then I ran Process Monitor and filtered for just File System Activity. Two things catch my eye. First, it attempts to query a library called faultrep.dll within the application directory. It's not there, so then it looks in C:\Windows\SysWOW64\Faultrep.dll.

It finds it and was successful, then finds it's locked, and is then successful again. I've attached a picture of the final actions it does before it locks up.

I'm not convinced this has anything to do with a specifc OS since it fails on every PC I've tried it on

Part of the point of listing all these debugging techniques (including using Windows XP) is to prompt you to do those tests again in a controlled way, and part of the point is that because the techniques are all quite different in how they work then it's very likely that one of them may succeed where others will not.

Whatever the cause of your problem, there will be some factor that is common across your test environments/platforms - be that faulty drivers, or potentially some unusual characteristic of the specific disks you are attaching - which does not exist anywhere else. Isolating that factor is crucial, and the more things we vary (including, if necessary, such tricks as hosting things inside a virtual machine with a multi-TB-size virtual disk to exercise Ghost more isolated from the host hardware) then the more we can discount them as potential root causes.

the command window freezes when Ghost freezes and logger doesn't continue

Just to be clear, when Ghost fails per your original report, is it a "freeze" (otherwise known as "hanging"), or is it a "crash" (the program exiting, usually with some alert to the effect that the program failed), or is the behaviour where the Ghost executable appears to "freeze" unique to the situation where you are using the logger.exe technique?

Also, as per the MSDN documentation I linked above, there are several ways to obtain the logger function; one is with the separate executable, which is a mini-debugger to make it easier to use. The other approach is to use the WinDBG debugger from Debugging Tools for Windows, which (like the USERDUMP.EXE approach on Windows XP) can stop the program before it enters Windows Error Reporting.

 Two things catch my eye. First, it attempts to query a library called faultrep.dll within the application directory. It's not there, so then it looks in C:\Windows\SysWOW64\Faultrep.dll.

This is what you'd expect from an on-demand-loaded call to the ReportFault API, which applications that include their own error-handling machinery like Ghost use to pass through faults to Windows Error Reporting. Note that use of ReportFault() exists specifically to trigger the Windows Error Reporting minidump capture mechanism I linked to the documentation for earlier.

The fact it gets to that point is a strong indication that whatever the problem is, it's been triggered and is being handled (by the Ghost application and/or via the OS itself) in a fairly normal way. Typically, some condition yielding a first-chance exception has occurred, and this has then been elevated and has invoked the normal machinery which would lead to a WER report and/or the GHOSTERR.TXT file being produced, depending on the exact timing.

If you're running on a platform like Windows 7, this means that the program has got to the point where the Windows Error Reporting minidump generation should work. If this doesn't work, then it suggests the underlying cause of the problem is severe enough that it stops the WER facility in the operating system itself from working, which would be unusual indeed.

It does also mean that the program is getthing a fair way along the path of elevating and handling an exceptional condition, so there will be a way to use a debugger like WinDBG to intervene earlier - if you run the program under a full debugger, then it will generally log all the first-chance exceptions as they occur, and once you have identified one that is a probably trigger for the full error-report process, the debugger can be configured to allow you to intervene right when the initial first-chance trigger occurs (and of course WinDBG also allows you to write minidumps using the .dump command). Plus, if you do need to use WinDBG, you then also have the option of using WinDBG to inject the logger trace extension.

[ Note that, as the above links explain, in normal operation you do see a LOT of first-chance exceptions, most of which are not errors but are things that are expected by and handled by applications. Unfortunately Ghost's code employs a rather unfortunate style that internally generates exception conditions to do "normal" things that are not exceptional at all - running Ghost under a debugger is a quite tedious and abnormally slow process as a result because so much extraneous "noise" is generated. ]

Have you considered the possibility that your Ghost executables have been corrupted in some way?

Not all USB drives transfer data faithfully - especially cheap ones, and maybe somewhere along the way the files have been corrupted and thus are crashing every time they run.

It would be a good cross-check to download a Ghost eval and test the executable from that on one of your systems.

Actually, since all the binaries we produced were digitally signed, the main thing to do should in principle just be to verify the digital signature - right-click in Windows Explorer, as the digital signatures are shown as a tab in the file property page, and then view the certificate details (which will trigger the full signature verification process).

The file digital signatures are produced by RSA public-key methods over a SHA1 hash of the file; if the digital signature passes that's one of the strongest verification checks you can use.

Yeah. It's not this. I've tried several executables and just for kicks, I downloaded the trial as well and the same issue occurs.

OK. So I tried using Ghost32 on Windows XP to see if a different OS would work.

The result is a good news bad news situation. It doesn't work, but an error message appears and an error log is written instead of just crashing, like it does on Windows 7.

An internal inconsistency has been detected

*********************************

Date   : Thu Feb 09 12:51:18 2012

Error Number: (8027)

Message: A GeneralException occurred

Version: 11.5.1.2266 (Dec 24 2009, Build=2266)

OS Version: Microsoft Windows XP Professional Service Pack 3 (Build 2600)

Command line arguments:

Active Switches :

       AutoName

PathName            : 

DumpFile            : 

DumpPos             : 0

FlagImplode         : 0

FlagExplode         : 0

 

Operation Details :

  Total size.........0

  MB copied..........0

  MB remaining.......0

  Percent complete...0%

  Speed..............0 MB/min

  Time elapsed.......0:00   

  Time remaining.....0:00   

 

A disk error occurred

Win32 error: (0x00000005)

Access is denied.

 

 

 

Generated at ..\DiskDriveAccessNt.cpp:150

 

Thread #3748 Call Stack

DiskDriveAccessNt::make

DiskManagerNt::constructor

sub_main

main

 

Call Stack

Address            Frame              Logical Addr              Module

0x000000007c90e514 0x000000000012efb0 KiFastSystemCallRet+0x0000000000000000

0x000000000012f2b0 0x0000000000000003 0x0000:0x0000000000000000 

End Call Stack

 

 

Start heap available: 754614272

Cur   heap available: 753410048

Total Memory:         1600565248

 

Allocated

  33500 ..\ghost.cpp:1511

Free

 

Fat details:

 

NTFS details:

----------------

 

NTFS Global Flags:

----------------

contiguousWrite=0 forceDiskClusterMapping=0 

inhibitCHKDSK=0 ignoreBadLog=0 ignoreCHKDSKBit=0

enable_cache=0 xfrbuflen=0 

last_attr_type = 0 

loadExact = 0 

sameSize = 0 

----------------

 

Disk Info :

  remote.............0

  drive..............0

  sectorsUsedCount.......0

  estimatedUsedCount.....0

  numPartitions..............0

  Version............0

  Full structure dump....

   {

      SVersion: 0

      SCylinders: 0

      SDiskFormat: 1

      SMbr: 

         0x0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0200 

      SIsSpanned: false

      SOs2Name: 

         0x0000 00 00 00 00 00 00 00 00 00 00 

      SFingerprint: 0

      SHeadsPerCyl: 0

      SectorsPerTrack: 0

      SRemote: false

      SEndOfImagePosition: 0

      SFlags: 0

      SPatchedFileCount: 0

      SDrive: 0

      SEstimatedUsed: 0

      STotalSectors: 0

      SPartitions: 

      [

      ]

      SSectorsUsed: 0

   }

 

 

 # Ord Boot Id Ext     First        Num       Last       Used NTFS

 

Disk Info :

  remote.............0

  drive..............0

  sectorsUsedCount.......0

  estimatedUsedCount.....0

  numPartitions..............0

  Version............0

  Full structure dump....

   {

      SVersion: 0

      SCylinders: 0

      SDiskFormat: 1

      SMbr: 

         0x0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

         0x0200 

      SIsSpanned: false

      SOs2Name: 

         0x0000 00 00 00 00 00 00 00 00 00 00 

      SFingerprint: 0

      SHeadsPerCyl: 0

      SectorsPerTrack: 0

      SRemote: false

      SEndOfImagePosition: 0

      SFlags: 0

      SPatchedFileCount: 0

      SDrive: 0

      SEstimatedUsed: 0

      STotalSectors: 0

      SPartitions: 

      [

      ]

      SSectorsUsed: 0

   }

 

 

 # Ord Boot Id Ext     First        Num       Last       Used NTFS

 

LargeMemoryAllocationFactory diagnostic...

==========================================

 

Heap available at construction: 754855936

Current heap available:         753422336

Total Memory:                   1600565248

 

Allocated

 

Environment Variables

=====================

 

ALLUSERSPROFILE=C:\Documents and Settings\All Users

APPDATA=C:\Documents and Settings\ernest.perez\Application Data

CommonProgramFiles=C:\Program Files\Common Files

COMPUTERNAME=HP-TEST-1

ComSpec=C:\WINDOWS\system32\cmd.exe

FP_NO_HOST_CHECK=NO

HOMEDRIVE=C:

HOMEPATH=\Documents and Settings\ernest.perez

LOGONSERVER=\\CTSDC4

NUMBER_OF_PROCESSORS=2

OnlineServices=Online Services

OS=Windows_NT

Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH

PLATFORM=BPC

PROCESSOR_ARCHITECTURE=x86

PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 2, GenuineIntel

PROCESSOR_LEVEL=6

PROCESSOR_REVISION=0f02

ProgramFiles=C:\Program Files

SESSIONNAME=Console

SystemDrive=C:

SystemRoot=C:\WINDOWS

TEMP=C:\DOCUME~1\ERNEST~1.PER\LOCALS~1\Temp

TMP=C:\DOCUME~1\ERNEST~1.PER\LOCALS~1\Temp

USERDNSDOMAIN=CTS-TX.COM

USERDOMAIN=CTS-TX

USERNAME=ernest.perez

USERPROFILE=C:\Documents and Settings\ernest.perez

windir=C:\WINDOWS

 

 

*********************************

Having had a look back over this thread, it would appear that the O/P is using Ghost32 to try and hot image a 64 bit installation of Win 7 - something that is not going to work, otherwise there would be no need for the Ghost64.exe that is installed with the Ghost client on a 64 bit machine. Throughout the earlier threads, it would appear that the Ghost executable is being run from the operating system itself and not from a WinPE boot environment.  It is not clear whether the XP testing is on a 32 bit edition or a 64 bit edition of XP, but I doubt this would work on a running O/S, even a 32 bit, if the client has not been installed, rather than just being run from an external USB drive.

Consequently, can we get a definitive description of whether the Ghost32.exe file is being run from Windows 7 64 bit, or whether the alternative of booting to WinPE (with the correct SATA drivers installed) and running Ghost32.exe from the WinPE command line has been tried?

The log information reports the drive as having no cylinders or sectors and nothing in the MBR, so assuming this is a working hard disk, Ghost is not getting access to the hard disk drivers.

So, this is relatively thin compared to the normal content of a GHOSTERR.TXT, but that's because it's occurred as almost the first thing that's happened. Ghost is still trying to build a map of how it can even get access to the disks in the system to gather information from them (on their capacity, partition layouts and so forth).

The most important thing is this section:

 

A disk error occurred

Win32 error: (0x00000005)

Access is denied.

 

Generated at ..\DiskDriveAccessNt.cpp:150

 

Thread #3748 Call Stack

DiskDriveAccessNt::make

DiskManagerNt::constructor

It would appear that while enumerating the attached disks to work out how to access them using a variety of operating-system-specific methods (there are something like six or seven of them in total, to cope with the need for multiple methods in DOS, platform variations between Windows and Linux editions, and peculiarities of SCSI devices), one of the Win32 API calls to access a volume has failed unexpectedly with an error and this has prevented something critical happening, leading to the program failing when it tries to use the memory that was supposed to be built by opening up the disk volume.

More will probably be apparent in a Process Monitor trace, as on Windows opening a raw disk or volume is done by the same API that opens a file (internally, the NT kernel is modelled on the UNIX notion of a single namespace; the Windows NT designers used the Mach Microkernel used in OSX and various other UNIX systems as a starting point). From the name of that, it may be possible to work out which specific thing that it is trying to access which is being blocked.

[ At this point I am reminded of a case which affected the GSS management client, where a program failure in the plug-in MACHCONF.DLL occurred while gathering the machine configuration. This turned out to be a case where an API call that never failed, failed due to a permission problem. On all this customer's machines, it was their policy to disable USB devices by an insane method (basically, some random guy's suggestion they turned up in a Google search, rather than any of the documented techniques in the MS KB's) which involved changing the permissions on the registry key for the USBSTOR service so that nothing, not even Windows itself, would open it. So on their system, some code which had basically run perfectly for nearly a decade on untold of millions of systems failed. ]

Now, this is something of an extrapolation based on thin evidence, much more thin that I would normally like to rely on. However, that's all there is, and my experience of similar cases and my recollection of the coding styles used in Ghost means that it's likely. Obviously, the code can and should be made robust against this kind of failure, but given the age and wide use of Ghost, most of those situations have already been flushed out over the years, so whatever is happening here is still quite unusual.

So it would be worth involving a developer; however, all the direct-to-customer support that the New Zealand team who made GSS did has long been dismantled, and so you can't easily get in touch with the replacment maintenance team without running the Technical Support gauntlet. That process generally takes *months*, and even a one-line fix (which is all this would be) then has to grind through a lot of Official Process to get done. It's worth doing, if only because it's the *only* way that the developers can get the political cover needed to do the work, but it's not quick.

The alternative we can do without access to developers is that if you can identify *what* it is that Ghost is trying to access and fail, then perhaps we can determine why and devise some workaround. As before, Process Monitor is the first port of call, looking for access-denied failures before Ghost enters its failure-reporting mode, followed by either logger or WinDBG with the api-logging plugin.

Alriight, so I started to run Ghost32 with Process Monitor on Windows XP. However, I received different results this time.

I believe I received an Access Denied message and Ghost didn't crash, was because the account I was using didn't have local admin access. So it never had the chance to even get to the point where it was crashing. Now when I try to run it again, I have local admin access and Ghost crashes again.

So we're back at square one.

 It is not clear whether the XP testing is on a 32 bit edition or a 64 bit edition of XP

Now that we've finally got a GHOSTERR.TXT, it's plain, regular 32-bit XP. "Windows XP 64-bit" is actually not Windows XP at all, but is built on the Windows 2003 kernel, and so is just really Windows Server 2003 without the "server" feature bits (so XP 64-bit had things like IPv6 networking features that didn't exist in plain XP, and some bugs unique to Server 2003 in things like Terminal Services). You can tell a lot from a build number :-)

Ghost is not getting access to the hard disk drivers.

Yup. It would seem likely that it's failing at the \Device\Hardisk level due to a permissions error; that's exceedingly unusual, because Administrator accounts generally have (or on Vista/Win7, will elevate to) full access to the the necessary rights (including things like the SE_MANAGE_VOLUME_NAME privilege.

This means the root cause is likely something done explicitly, whether the action of third-party software or a piece of common configuration, and wouldn't occur in a stock OS install.

Regardless, it's still worth unearthing the details so there's a clear path to a proper code fix, as there is a code-level fault in Ghost and that is something that is always worth fixing, so that if the problem ever recurs there will be a diagnostic trace which says "here, dummy" instead of just bailing out.

Nigel,

I replied to your comment above. The ghost error file is irrelevant. It cannot help us in this endeavor and does not relate to this issue in any way.

That XP machine I used was just a random computer I found in IT. I logged in with my domain credentials, but didn't have local admin rights. Since XP doesn't have UAC and Ghost did not alert me to a permissions issue, I couldn't determine that not having rights was the issue. Ghost32 couldn't even query the drives because it didn't have access to them due to a lack of, in my account. But, that's an exception to this case. It has nothing to do with the problem.

When I finally did get local admin rights, the normal issue occurred. Ghost32 crashed and no error log was produced.

So we're back at square one.

Not exactly, since there are still steps I've laid out above that you can try. The process of diagnosing something like this - things that fail every time are easy - just requires a combination of being systematic and trying to gather as much data as possible.

On the "data" side, there is still lots to do to capture the diagnostic data like a memory dump (which although it isn't directly that useful to us without access to the program code, it's critical to be able to supply to get any code problem actually fixed).

First, reproducing the issue under Windows XP means that you *will* be able to use USERDUMP.EXE to get some form of memory dump from the process (although it may take a little to work out just the right trigger to use). The same should also be true of running Ghost under WinDBG, which also gives you the ability to see the first-chance exceptions as they arise during program startup and can also host the Logger trace facility as explained in the MSDN documentation linked above.

The second part of the methodical diagnosis process is - once we have captured the all-important evidence of the problem in its original context, for expert analysis - to work forward from a known good state, as I also alluded to above. This means with a clean system (such as one running in a VM context, if physical machines are hard to come by) that is as vanilla as possible, without any of the potential third-party factors such as drivers, third-party applications, or any of the other bits of potentially confounding cruft that "standard operating environment" machines tend to have.

If you can reproduce the problem in an *absolutely stock* Windows install, that's important information too. If you can reproduce the problem in a stock Windows install in a VM then that's pure gold.

After all, none of the people working on the product know how they can reproduce the problem because none of their equipment has ever failed like this, and you haven't been able to supply any detail which might even provide a useful starting point for reproducing this. One of the things that ideally needs to be figured out is how to make this fault happen in their contexts, where they are starting from clean systems.

For instance, one of the key factors might even conceivably be the current *content* of the disks you are attaching; if a totally stock Windows install in a VMware VM fails when you attach a large USB hard disk directly to the VM, then the most likely possibility is that the content of that disk may be a factor, in which case that becomes the primary line of investigation.

Essentially, we have a big matrix of potential causative factors to rule out. Absent any other information, that that means constructing and executing tests where we vary factors under test to try and establish which factors are relevant and which aren't, and record the details of those tests. 

If you can get a starting point that works, and an desired ending point that fails, systematic bisection will eventually lead you to the root cause. It's tedious and time-consuming, but it's the thing to do. One of the greatest tools in the world being a good old laboratory notebook and a pencil, something I would always take with me when our QA folks would come up with a helpful "doesn't work" bug report and I'd have to camp in the QA lab and observe.

@ernest

Do you need to install any device drivers for your larger USB drives?

I have a number of portable USB drives of 500Gb and less, and these all work without any driver requirement.

However, when I purchased a 1Tb USB drive, for the first time I found I had to install an SES driver (provided on the USB hard disk) in order to address the main storage area.  

It occurs to me that you may be running into a similar issue with larger drives.

As an absolute test, why not hook your target 750Gb SATA drive directly to a SATA port (rather than via a USB to SATA converter) and then try imaging. At least that way you can establish whether the converter is the issue.

That's an interesting idea. And it would make sense because we PXE boot WinPE on large HDDs and Ghost them fine. I'm kind of mad I haven't thought about this earlier. I'll look into it today.

ernest.   you are not alone   I am  having the  exact same issue.     I just  purchased a 3tb  usb 3  external harddisk... to store  static  images ,  files etc...  figure  quick and easy  instead.

I have  bart xp cd... winpe   and   windows7  boot cd's    on bart  have  ghost 11.5  ...

on thumb drive and  the 3T   hard drive I also have   ghost32

all 3  cd  boot  fine.  I can see access the  internal  hard drives... I can access  usb  thumb  I can access the 3 TB  usb atached  HD  and  move  files about.

I load  ghost  from  bart cd  under xp... or  from thumb    or  the  harddrive  the  ghost program  flashes  an  dissappears..    I repeat with  winpe   win7  cd... same.

I repeat  with  a 500 gb  usb 2.0  external  .... all work I can  load ghost  create images  etc etc...

I suspect  as  you  this version or  revision of  ghost    has  some issue  seeing  the  physical  device  due the size....  as it  looks at the whole  device...

If you are using a USB-3 external drive via a USB-3 port, have you installed the necessary USB-3 drivers to support your hardware into BartPE?  I certainly had to do that with WinPE if I wanted to run through the USB-3 port. There were two drivers required - one for the motherboard chipset and one for the external hard disk.

Nigel willl correct me if I'm wrong, but I'm sure he has posted in the past that the Ghost software was tested with all the emerging technologies such as GPT and EFI bioses many many years ago.

There's zero wrong with Ghost in terms of mere size; the issue is something else, most likely something like a fault in the SCSI miniport driver - since the USB standard for such hard disks uses the SCSI command set tunneled over the USB bus protocol; there are presently something like 5 different normal SCSI commands for block reads, of which only the most recent ones support 64-bit LBA, while most of them have much smaller limits, most notably at 2Tb, and similar oddities exist throughout the SCSI command set.

So, while Ghost is normally perfectly happy with large drives over SATA or eSATA, and large drive arrays (notable because drive arrays in the Windows driver model basically always end up represented as SCSI devices even if the underlying bus isn't *quite* SCSI), there's quite possibly some kind of fault in the SCSI miniports for USB where the handling of the variant SCSI commands for >2Tb drives isn't done properly. If this is so, there's possibly some workaround that could be implemented in code to tip-toe around whatever sequence of operations triggers the fault in the problematic driver, but that would require some rather more clearly defined set of reproduction steps from the folks affected.

Same problem with a brand new usb3 WD 3TB My book Essential external drive just bought it from amazon connected to an USB2 port.

Any workarround that really works?

Make your USB3 hard disk bootable with WinPE and then run Ghost from the WinPE command prompt. If you need drivers to mount your system's hard disk, you can test drivers using DRVLOAD (path to INF).

Hey Everyone,

I'm sorry it has taken me so long to get back with you all on the status of this issue. It took me so long because I took EdT's advice and ordered some new cables. The whole purchasing process took much longer than I expected. I just received the new cables today.

I knew this was a long shot and I honestly didn't expect it to work, but much to my surprise, it worked without issue! So it turns out our old cables were the issue. I imaged a 750 GB drive earlier and had no problems.

Thanks a lot everyone for sticking with me on this and helping me find the solution.