84 replies to this topic

[pscEx]

vdk from psc, vdk x64 from sherpya fails.
(and i believe original vdk fails too)

They do not fail!

They only are prohibited by the OS to free a driver service which is in use anywhere.
It should be in the responsibility of the Ghost 14 script's author to find, why a service remains in use after the script has been processed.

BTW: The changes I made:

In some unusual / error situations VDK pops up with a message the user has to click.

Because VDK usually is started by 'Shellexecute,HIDE, ... VDK would hang for ever, waiting that the user clicks in the INVISIBLE message box.

I added a timeout for that.

Peter

[Lancelot]

Peter

*
fail fixed in previous post....

*

It should be in the responsibility of the Ghost 14 script's author to find, why a service remains in use after the script has been processed.

There is no such a script.

as written before and here is specially for you knowing you dont like post numbers/links and dont like to read long:

@all:
since post44 topic is about vdk.exe and some symantec guys making ugly things resulting vdk.exe not working.

Last notice/reminder: vdk is not mandatory, imdisk can be used for same purposes, an example: bootsdi of nativeex uses imdisk (so far i read ).

I would like to use vdk , for 2 reasons: 1) no installation required, 2) real hd image investment

My only concern is LiveXP using vdk with reasons written before , today symantec tomorrow tuctec can cause such an issue (or maybe Mista8 sp2).

This issue reported by joakim on another topic for BootSDI failure, but joakim didnt indicate ghost14/or/besr installed to his hostos. At current topic i installed besr just for curiosity and when i wrote my lodr pack result i wrote my concerns for suspecting this vdk issue. After dera's confirmation we find the reason.

+For testing, install ghost14 trial or besr trial to your hostos and use vdk more than once. (ps: i dont use either of these utility, my real concern at this topic is supporting lodr packs and finding "missing" thing(s) on LiveXP )


There should be a "permanent" solution to solve any future(&today) vdk usage , we once had this with vistasp1 and luckly we passed over it, now same luck (method,) dont work..... Yep realhd image not rmandatory for ramdisk booting but (written)......... Well you are the guru, i guesshope no need to write more.

[joakim]

I'm not 100% sure it's related symantec products as I have the issue but no symantec product installed on host.

VDK.exe still works manually, but not more than once for every boot when building livexp(bootsdi) and moa(ramloads).

Why would "vdk.exe open 0 file.img /rw" and "vdk.exe close 0" work, but not with the building engines that use different command line?

Joakim

[Lancelot]

joakim

what is your hostos ?

[joakim]

xpsp3 norwegian

[Lancelot]

joakim,

Yep i understand your case is a bit different, you can use vdk directly with a batch (.cmd or .bat !!??) but cant use vdk either with wb nor with sanbarrow's utility.
So this is proof for other utilities (maybe commercial maybe not) than symantec causing vdk issue. I hope you find the reason (tuctec ) so all of us can reproduce.

VDK.exe (x64) dont work manually after installing besr, i guess same for dera too with "vdk x86 psc"+"ghost14"


Well exception number is not 1 now , we dont know the new "tuctec" utility but obviously there are 2 vdk issues ;)
For livexp, there seems to be 2 ways
1) solution for current vdk issues (maybe guru(s) may help too )
2) adding imdisk optional to bootsdi, with a checkbox "Force imdisk usage". If checkbox not selected first trying vdk, and if fail continue with imdisk... install imdisk... etc etc. ;) ..... (still crying...)

[dera]

I can use
'vdk_WB.exe open 0 BootSDI.img /rw /p:0 /l:R:'
and
'vdk_WB.exe Close R:'
commands with success more than one times,

but when also the 'vdk_WB.exe stop' and 'vdk_WB.exe remove' commands used (and fail)
I cannot use 'vdk_WB.exe open' again
(will fail too)

[joakim]

That clarified a lot because I never use stop and remove on the line and thought it was something else passed on the command line.

The workaround seems to be to only use open and close on the command line.

Good work!! Gotta go now.

Joakim

[sanbarrow]

good suggestion - I'll try that too in moa-setup.

[Lancelot]

Thanks dera

I dont like the solution/workaround , i guess you already know the reason. Instead I would like a way to force uninstall.....
But
since it is a workaround and since there is no guru support (and I love vdk ), I put this optional on scripts + not to get complains for using vdk i selected as default.

@joakim
I hope you find The "tuctec" utility which cause this error in your trials (crossing fingers 1) for your finding "tuctec" 2) hoping "tuctec" is not a commercial (or too commercial) product). I believe "The Day" will come in future where there 'vdk remove' or 'vdk stop' "must" be used with a "tuctec" utility..... All we need a "luck" with a "guru" living "The Day" (from my experience it may be from 26 days to 6 months and can be more...) . Maybe If you can find The "tuctec" utility on your hostos which cause this error, this finding "MAY" help scheduled "The Day" earlier.


@all
scripts updated on LiveXP server. Tested with installing besr on hostos and works nicely.

[was_jaclaz]

This thread is becoming a mess.

Let's get a bit rational, please.

I gave those links to Lancelot, expecting he would EXPLAIN the matter, instead of further confusing it:
http://www.boot-land...?...=1662&st=59
http://www.boot-land...?...1580&st=216
http://www.911cd.net...o...21242&st=34

Since noone appears to actually follow links and READ them in their context , let alone actually READing the VDK.EXE readme.txt, let's start from scratch.

Re-read psc's post above:

They do not fail!

They only are prohibited by the OS to free a driver service which is in use anywhere.
It should be in the responsibility of the Ghost 14 script's author to find, why a service remains in use after the script has been processed.

VDK commands are "telescopic" so:
INSTALL will install the driver.
START will INSTALL and START driver.
OPEN will INSTALL and START driver and OPEN given image.

CLOSE will close (unmount) the given image.
STOP will CLOSE all images and STOP the driver.
REMOVE will CLOSE all images and STOP the driver and REMOVE (uninstall) it

Ideally one could use ONLY the OPEN command (that will also INSTALL and START the driver) and the REMOVE command (that will also CLOSE the image and STOP the driver)

BUT:

• if anything "hooks" in ANY way the driver, the REMOVE command will fail.
• if anything "hooks" in ANY way the the mounted volume or the connected virtual \\.\PHYSICALDRIVEn, the STOP command will fail.
• if anything "hooks" in ANY way the the mounted volume the CLOSE command will fail.
  THEN:
• if EITHER the REMOVE or STOP or CLOSE commands failed, for ANY reason, NO subsequent INSTALL or START will work anymore

SO, in order to be "safe and "foolproof" (at least theoretically) :

• the INSTALL, START or OPEN commands should ONLY be executed at the beginning of a "session"
• the STOP and REMOVE commands should ONLY be executed at the end of a "session"
• ANY of the above commands and all the "intermediate" ones, LIMITED to CLOSE and OPEN, should ALWAYS be executed ONLY after having checked the status of the driver using VDK.EXE DRIVER command and parsing it's output.

I had guessed that the above was already solved at the time of this:
http://www.boot-land...?...1580&st=216

I hope that this info helps.



jaclaz

[joakim]

I am well aware of and have read those links including the documentation for vdk.

What is still not solved is the source of the hook that apparantly under certain circumstances is not unhooked with the curent command line used in the bootsdi script and moa's rambuilding.

It has nothing to do with my lodr packages and further discussions about this issue (if at all) should be continued elsewhere.

Joakim

[Lancelot]

It has nothing to do with my lodr packages and further discussions about this issue (if at all) should be continued elsewhere.

I agree with joakim, since the end of post43 (as written many many many times before) issue is vdk not having force uninstall or with more technical force unhook etc......... Better to split to a new topic if agreed, i wont post anymore about this here... (not again......)

[was_jaclaz]

I agree with joakim, since the end of post43 (as written many many many times before) issue is vdk not having force uninstall or with more technical force unhook etc......... Better to split to a new topic if agreed, i wont post anymore about this here... (not again......)

And I agree with you about splitting the topic.

Now WHERE should the "Main one" about Ghost 14 and BESR go? Surely not where it is now (Websites)

And WHERE should the "VDK related" one go? (again not where it is now)

However to sum it up:

• evidently something "hooks" VDK
• VDK cannot be "unhooked" or forcibly shut down (and, even if it could it WON'T be the right way to go)
• there is no need to INSTALL and/or START the service more than once per "session"
• there is no need to STOP or REMOVE the service if not at the END of a session
• NO command should be issued to VDK if it's status has not been determined before
• using the OPEN and CLOSE commands more then once per session should not create problems

Thus the code in .scripts that create this problem should be corrected as per above AND the reason for the "hooking" should be searched and found.

Responsibility for this is of the .script Author(s).



jaclaz

[Lancelot]

And I agree with you about splitting the topic.

Thanks , something both agree

Now WHERE should the "Main one" about Ghost 14 and BESR go? Surely not where it is now (Websites)

well websites even not good for the current lodr topic . But also apps script section is not suitable too, maybe we need a new branch "General LODR" so joakim can put all his lodr packages infos there. (My expectation number will increase in time )

And WHERE should the "VDK related" one go? (again not where it is now)

Maybe http://www.boot-land...hp?showforum=52 since we had this issue first with LiveXP bootsdi with title sth like "Vdk STOP or REMOVE effected by some utilities" (well not totally correct topic since this is not directly LiveXP related) You know better....

Thus the code in .scripts that create this problem should be corrected as per above AND the reason for the "hooking" should be searched and found.

already corrected BUT as written before END of a session cant be determined by the project/script so STOP or REMOVE never used.


As written many times before:
This topic in fact have no relation to vdk issue except the utility name used in LOdr package of Joakim. Joakim method of creating lodr package dont effect hostos so there will be no problem using vdk STOP or REMOVE . But there is still another unknown utility (tuctec) causing same issue. When found better reported on this new topic....

[joakim]

My lodr packages does not fit any section better than the other.

If a LODR or General LODR section could be created, that would be great. As no such section exist, I would be very happy if someone with the rights could create such a section, and make my life a little bit easier when choosing where to post my packages.

Websites surely was a random pick.

Joakim

[Lancelot]

@jacklaz

Lodr packages can be created with a batch or winbuilder (well i plan to use winbuilder in future when found missing things)
Maybe a subsection here
http://www.boot-land...hp?showforum=22
or anything you like

LODR alone is not a good name since sanbarrow named "LODR packages" but infact most essentials are "LODR for moa packages" since only a moa user can quickly and easly use them. They shortly called LODR and having same name can mix new users mind.

What Joakim tries to do is making "LODR General" packages which can be used by VistaPE, LiveXP (still lookin for the missing stones ), moa, (and i guess will work with sherpya, reatogo and some other builds never tested). That is why i name them with General not to mix accidental misnamed "LODR packages".

Well maybe you have a better idea for naming . "LODR General" , "LODR Universal PE" , "LODR Inter Galaxy PE" , "LODR Outer Galaxy PE" , "LODR Cosmos PE" ..... . But i believe it will be a good idea to have a section with any name anywhere on boot-land.

[joakim]

Universal LODR for PE" or "Universal LODR" would fit best on my stuff, as it is meant to be used on any PE from xp/2k3vista/2k8, preatty much universal in windows PE terms.

Or maybe a LODR section with subsections..

It is really in distinction to the App Scripts section as that is for buildtime use, and LODR is after bootup.

Joakim

[risolutore]

correct me if I am wrong, so it is actually possible to use BESR 8.5.3 on vistaPe rc1a using the lodr.script avaiable from livexp repositary?

[Lancelot]

@risolutore

Correction:
it is actually possible to use BESR 8.5.3 on vistaPE (due to joakim posts)
NO need (MUST NOT) transfer lodr script from livexp to vistape
Test with your vistape and share us the result

About "LODR-U BESR" with LiveXP:
Currently livexp have sth missing causing it not starting LODR-U BESR 8.5.3 But since LODR-U BESR 8.5.3 starts with pebuilder based PE, it will be available on livexp too.

[risolutore]

from joakim readme

These 2 apps are real bloatware that depends on many things. If any of the dependencies are missing the apps will fail loading correctly. Dependencies;

- Visual C Runtimes 2005

- DotNet 2

- winmgmt

- EventSystem

- SwPrv

- VSS

- MsiServer



Other requirements;

- Writeable %SysteDrive% (writeable X:\)

- Keep LODR package in correct directory structure



My interpretation of LODR

Forget about what you've heard of lodr packages for livexp or moa. My packages are slightly different. The principal is to collect the application binaries with a script and have all the application files put in a named folder under a root folder, LODR (for example G:\LODR\besr853). In the app folder you should place the loader for that specific package (for example besr853_LODR.exe). Execute this one only once for each bootup/restart. The loader will register dlls and install drivers and services and apply some required registry entries. If the application is run/restarted more than one time, then execute through the generated shortcuts on desktop or startmenu, or the main executable directly. The loader have a check for PE-mode as a safety to prevent execution in non PE-mode. As a matter in fact the LODR packages by Symantec can be used to install these two apps by toggling the minint key in the registry, and will then work on a real installed system.

[Lancelot]

@risolutore
I missed the point in your post !
anything contradict to my previous post in joakim's readme ?
or is there a hidden question I missed due to language problem ?

[joakim]

correct me if I am wrong, so it is actually possible to use BESR 8.5.3 on vistaPe rc1a using the lodr.script avaiable from livexp repositary?

The tests that went good on vistape was from a build built 1.5 year ago. Do not confuse my package with the winbuilder lodr.script. That is slightly different and will require tweaking to get working with.

I must admit it is rather tricky to get going in vistape(vista/2008). Especially with 2008 sources. I will look into it again and finetune the instruction. It is also part of the reason why I have invited people to discuss some of these services (vss & wmi) for PE on the nt 6.x platform.

There is currently something in livexp (at least my builds), that prevents both besr853 and ghost14 to see the local disks. I was also working on something there, but lost interest as there was no progression. It was, by the way, an integration of certain classes in setupreg.hiv, mainly focusing on integrating some missing bits and peaces from MOA (registered dlls).

MOA is currently the, by far, the easiest bootcd to run it from.

Joakim

[risolutore]

Thanks Joakim, I undestand the differencies, guide me towards the best way to have a working BESR-Ghost14 on VistaPe, or on WinPE 3.0.

[joakim]

Sure, I will do so in the next few days. Just have to dig into it indepth again.

Joakim