Cannot run sdimgr.wsf on XPE Image

[Guest]

I am trying to use sdimgr.wsf on a small XPE image.
I have the Windows scripting component installed and am registering
sdiaut.dll.
Both the sdimgr.wsf and sdiaut.dll are in the system32 directory which is in
the path.

When I run the command:
cscript sdimgr.wsf recover.sdi

I get
Input Error: Can not find script file "c:\windows\system32\sdimgr.wsf"

This is a minlogon image and folder rights are set to full for SYSTEM.

Any ideas?

 

[KM]

John,

I don't know why you see the error.

Try to specify the full paths for all the files in the command.

Any chance for you to monitor the launch with Filemon? Then you would see for what files the 'open' requests are occurring.

 

[Guest]

Turns out that its looking for mlang.dll. Language model manager? Not even
sure what that means.

In any case, thanks for the tip.

 

[KM]

John,

Just add "Primitive: Mlang" component to you image.

Actually the Mlang is delay load module dependency for cscript (WSH). Likely a bug in the component.
The Dll will be in your image if you happen to include IE or Explorer (Shell32) but on a Minlogon image it is often not the case and
therefore you sensed the bug.

 

[Guest]

Thanks KM. The fact that it doesn't get loaded for you on XP Pro is pretty
bizarre but... oh well. I'm still pretty impressed that MS figured out as
many of the dependencies as they did. Now if they could just break a few
dependencies so that you could make a Network image in less than 80MB...

thanks again,

John

 

[Guest]

Well, its running now but if I try to do

sdimgr.wsf recover.sdi /writepart: /yes

I get
the data area passed to a system call is too small.

Any ideas on this one?

 

[KM]

John,

Thanks KM. The fact that it doesn't get loaded for you on XP Pro is pretty bizarre but...

It could be that on your XPe image (or any XPe image by default without special registry entires added) the code page translations
must be done for unicode files (that wsf is wide character based text).

oh well. I'm still pretty impressed that MS figured out as
many of the dependencies as they did.

They have sources for the apps which makes it much easier

Now if they could just break a few
dependencies so that you could make a Network image in less than 80MB...

We are all hoping the LHe will be better at this.

 

[KM]

John,

I have not idea :-(
I never saw the error message you mentioned. Is it coming from cscript (WSH) or the sdiaut/sdimgr.wsf? (I couldn't find it there)

Again, the Filemon and Regmon are your friends there to figure out the issue.

 

[KM]

John,

I just realize that it is the kernel32.dll that gives you the error message.
Are you seeing the error message after you reboot to the image "expanded" with sdimgr?

 

[Guest]

No it never gets that far. The error comes up immediately. It appeared to
be coming from sdiaut.

 

[Guest]

KM, more info on this,

I decided to re-create the SDI file using readpart. Oddly when I did the
writepart command directly afterwards it said access denied but a second time
appears to have worked.

My original SDI test file was an experiment with booting a CD from a ramdisk
using an SDI file. Those instructions include a pack command on the sdi file
(along with the boot blob). I wonder if that might have been related.

In any case, I'm a little concerned about the write, nope, write, ok
response I got. But perhaps that is just a timing thing on a lazy write?
Hmm. A second test did exactly the same thing. access denied once and then
appears to work.

John

 

[KM]

John,

I recall seeing the access denied problems when I had the SDI file on read-only medium. Although I only tried to use it with
writepart command, it required write access to the sdi file.

Did I get it right from your message. You fixed the problem by re-making the SDI file? The old SDI was giving you that strange error
message about the small data area passed to a system call, right?

 

[Guest]

KM,

I also saw the access problems on read-only medium (although a network
folder with only read access seems to work fine - go figure). In this case,
I am running it from a PCMCIA CF adapter.

But yes, remaking the SDI file made the small data area error go away.

John

 

[KM]

John,

I also saw the access problems on read-only medium (although a network
folder with only read access seems to work fine - go figure).

Interesting.. This very case (the read-only network share) was the exact issue for me. The sdimgr failed on writepart command when
the sahre was set up read-only.

In this case,
I am running it from a PCMCIA CF adapter.

Removable. Always a problem on XP OSes.

 

[Guest]

KM,

As I re-read my original message I realized when I was doing the read only
network drive I was using sdi2hd in DOS. Obviously totally different
scenerio.

So, removable always a problem? What do I do then? Just keep running it
until it works? What if it doesn't?

John

 

[KM]

John,

As I re-read my original message I realized when I was doing the read only
network drive I was using sdi2hd in DOS. Obviously totally different
scenerio.

Ah! Then we are on the same page.

So, removable always a problem?

Almost always (vs fixed) :-(

What do I do then? Just keep running it
until it works? What if it doesn't?

Well.. Since yo umentioned it works just fine for you on second launch, you can do either:
- Keep it as is and document the process so that your devs/testers have to run the command twice. Or provide them with a batch
file.
- Monitor the first launch of the command with Regmon and try to catch what's getting changed in the registry so that to have it
integrated in first place to prevent the error. Don't know if you would be able to catch the right reg.entries but it may be worth
to give it a try.
- Mark the card as fixed and use IDE adapter instead

 

[Guest]

I guess I'll probably try to see if regmon shows anything interesting. The
fact that I was able to reproduce the problem by running it the third time
makes me less than hopeful. I may have to GUI this anyway so if I catch the
stdio I can just give it a few tries.

Unfortunately, this is for the field recovery of a closed box so IDE won't
be an option.

Thanks KM,

John

 

[KM]

John,

Unfortunately, this is for the field recovery of a closed box so IDE won't
be an option.

How about USB? It is getting pretty popular to have a Usb key for image recovery option.
I guess most of us here have done that at least once.

 

[Guest]

We want to allow both USB and PCMCIA. But that is still a removable drive,
no?

 

[KM]

John,

You can mark USB hard and flash disks as fixed.
http://www.google.com/search?hl=en&...edded&q=USB fixed disk&qt_g=1&lr=&sa=N&tab=gw

Read this doc. It may be helpful to you. http://www.microsoft.com/whdc/device/storage/usb-boot.mspx

Even with USB Removable drive/keys, you can still have a stable recovery scenario. It is just that you may be able to make it
bootable only with *some* brands but not all.

Btw, although I like SDIMgr for the recovery option, you don't necessarily have to stick with this approach. You can
prepare/partition/format the target media and copy the image other way (just xcopy, e.g.).
After all, you can always switch to DOS. then you will just need to use tools that support Long file names (LFNCopy, or a Zip/Unzip,
etc.).