36 replies to this topic

[Arvy]

Am I alone in noticing recent problems with LiveXP's BootSDI.script hanging between the first and second iterations of its RAM drive building process? There is no error message, but it just sits there forever with a "PLEASE WAIT" message, apparently spinning its wheels until cancelled manually. (I've waited for up to an hour before finally giving up.) Thereafter, the log shows no error other than the manual abort STOP.

Don't know if there's any connection, but I noticed no such problems prior to the recent addition of all those RegAddBoot "compatibility" lines to some of the LiveXP scripts. It may be coincidental. But, in most cases, notably with the 7-Zip_File_Manager_SJL.script which contains many of them, the BootSDI problem seems to disappear when I converted* all those script lines back to reg_add,0x2 equivalents.
__

* Actually, I just grouped them all into their own script section to run conditionally for VistaPE, Win7PE, et al: If,Not,ExistFile,%source_win%\TXTSETUP.SIF, ...

[Lancelot]

I guess coincidental
http://lancelot.winb...1123_195635.rar

forever with a "PLEASE WAIT" message

In bootsdi.script there is
Message,%infomassage%,Information
this is a precaution where imdisk fails to dismount (so asked user to do manually detach with message), but a user may accidentally click winbuilder and since message goes back of the wb interface......

search
SetVar - Sucessfuly changed the value of [%infomassage%] to: [Failed to detach ImDisk HDD.#$x]
in the log I sent.

ps: grouping workground is a bit .... , For now I prefer waiting news from JonF preloader.

[Arvy]

I guess coincidental
http://lancelot.winb...1123_195635.rar

Perhaps. But whatever the underlying problem may be, it was definitely NOT a dismount failure in my own case. I checked everywhere very carefully for any such message or indication of any kind.

ps: grouping workground is a bit .... , For now I prefer waiting news from JonF preloader.

Huh?! Grouping script items for conditional execution is a bit what? If there's some real issue with conditional execution groupings, the simple alternative would set an initial true/false variable and preface the relevant individual script lines accordingly. Preferable to just commenting them out entirely IMO. For example:

[variables]

If,ExistFile,%source_win%\TXTSETUP.SIF,%IsPE1%=True

If,Not,ExistFile,%source_win%\TXTSETUP.SIF,%IsPE1%=False

...

[process]

If,%IsPE1%,Equal,True,reg_add,0x2,...

If,Not,%IsPE1%,Equal,True,RegAddBoot,...

I thought I was doing something more or less equivalent to your own earlier suggestion for using a RegAddBootIf process. Anyhow, it cured my own BootSDI.script runtime problem, whatever it was. Just thought I'd mention it here FWIW.

[Lancelot]

Perhaps. But whatever the underlying problem may be, it was definitely NOT a dismount failure in my own case. I checked everywhere very carefully for any such message or indication of any kind.

I %100 believe you, but i can not reproduce here.
In my first trial (previous post) I had unmount failure which requires my manual unmount, interestingly on my other trials (clean temp used) this did not happen.
I also have some random issues that wait me to find a reproducable way .
ps: In the past I was famous with finding unreproducable issues and finding a way to reproduce (or clearly identify) them
At least now i put an echo message to bootsdi to prevent user missing the box.

Just thought I'd mention it here FWIW.

Thanks a lot , Another note in my mind to catch

Huh?! Grouping script items for conditional execution is a bit what?

The condition you used (IsPE1...) is a bit wrong (yes valid for the current situation but..), in fact the real condition is about the project if it can handle the situation. (either pe1, pe2, pe3)

I thought I was doing something more or less equivalent to your own earlier suggestion for using a RegAddBootIf process

yes, the last version of RegAddBootIf was checking If the project have support for such a condition.

Galapo asks other projects to support the feature since it is their fault not to support at first place (which is the core of the problem), hopefully (and only one pe2/3 admin) JonF responded with clearing the situation. (Thanks to JonF a lot)

JonF have an idea to make a preloader for vistape which as a result we will not need most of regaddboot lines and regaddbootif goes to history pages.

If preloader idea fails (I hope not), than better to set condition on script project so when pe2/3 projects starts to support, they can easly change the condition on script.project which as a result we won't need to rewrite the scripts. (Still I do not like to make 2 entries for one registry on a script, well if it is what I should to for the interproject scripts, with not like the idea I would..)

[Arvy]

My %IsPE1% example was only intended as an illustration of the general methodology. As you say, it worked for my own particular purpose and so was not "wrong" in that limited sense. But the true/false test conditions could, of course, be whatever might be considered appropriate for any wider set of API distinguishment circumstances which would allow the same general approach to the overall issue.

The real "root of the problem", as I see it, is a whole range of activities whose possibilites are currently restricted and more or less "locked in place" by some "proprietary" constraints of a previous developer who appears to be no longer actively engaged in the developmental process.

In the circumstances, recalling your earlier question about script writers(!) being "selfish", one is tempted to wonder about the true applicability of the old "Dog in the Manager" fable, but I suppose I'd better not. The issue of who should be accomodating whom is always a matter of some judgement.

[Lancelot]

In the circumstances, recalling your earlier question about script writers(!) being selfish, one is tempted to wonder about the true applicability of the old "Dog in the Manager" fable, but I suppose I'd better not.

I am not sure the meaning of this, (after reading this).

So far I know, noone on the discussion topic acts like the Dog in the fable".

We currently have 2 path to go and a time to wait to see which path. I can not find the relation with the fable.

[Arvy]

I wasn't referring to anyone in this particular discussion, Lancelot. Looking beyond, however, can you not perceive any vague similarity to any individual anywhere who currently eats no hay himself but who bars from the manger those lesser creatures who are trying their best to get there? If not, just forget it. It was merely a passing reflection of my own perspective on the more fundamental "roots of the problem" that you mentioned.

As for waiting to choose a path, that would be fine. But, in fact, you haven't actually just waited, have you? To the contrary, you've actually eliminated (commented out completely) during the interim one alternative in favour of another. I, on the other hand, was offering to whomever might find it worthwhile (and have actually implemented for myself) a middle path that allows both optional methods to co-exist during the "waiting period" based on setting a single flag, either in the common API or at the top of any individual script.

As I said, I thought that's more or less what you yourself were suggesting earlier, and it seemed at least partially consistent with Galapo's concerns as well.

[Lancelot]

Hi Arvy,

It is a puzzle for me to read your posts which i like a lot

Well I choose to leave current regaddboot lines on scripts for the "waiting period" which seems to cause trouble to you because of an unknown(unreproducable) reason. So as a result I would also advice anyone whom have similar issue to follow temporarly the path you introduce here. (changing all scripts today with txtsetup flag and again changing all for the new flag (what ever the path, maybe only replacing) is a bit too much work, I hope you understand my reason of waiting which i guess will not be too long.). However I believe this is not an issue of regaddboot and I do not know what cause this , that is the reason I did not change the script quickly as usual, only hoping next similar report would enlighten us more. Even after waiting period (where most regaddboot lines acts as reg_add for livexp) I believe this issue will be reported again.

Just an idea, have you tried vdk option instead of imdisk ? (with using regaddboot lines on 7z)

[Arvy]

(changing all scripts today with txtsetup flag and again changing all for the new flag (what ever the path, maybe only replacing) is a bit too much work, I hope you understand my reason of waiting which i guess will not be too long.).

Yes, I understand your reason. However, it took me less than 20 minutes to revise the 8 or 9 scripts involved using a text editor (IDM UltraEdit) that handles regular expression "search and replace" functions. And it would take even less time to "undo" now that their process branching is based on a single flag item. Anyhow, if anyone does want the revised versions "ready made", they can be downloaded from my own FTP server at ftp://ftp.virtech.org -- login with user name: anonymous@ virtech.org, password: anonymous (Use a proper FTP client rather than a browser.)

Just an idea, have you tried vdk option instead of imdisk ? (with using regaddboot lines on 7z)

No, sorry, I haven't tried that. Having made the above-noted script revisons, I no longer have any runtime problems with BootSDI. In fact, it now runs perfectly even if I deliberately set the script process selection flag falsely to make it use RegAddBoot in all cases. I guess, as you say, it's just one of those mysteries that may resurface with more and clearer info later on.

[Lancelot]

it took me less than 20 minutes to revise the 8 or 9 scripts involved using a text editor

Well, that is why i am a turtle

Thanks for sharing the package

[Arvy]

Well, I thought I had it beat, but the BootSDI.script hung again today. The only changes since my last successful run were a few updated LiveXP items, including Galapo's latest Common_Api.script update (v15rev3 for LiveXP) and the most recent update for the BootSDI.script itself (Version 120).

There are still no error messages of any kind whatever, other than the manual abort STOP after waiting for about half an hour. The first iteration of the script's RAM disk building process completed and dismounted succesfully and it deleted that preliminary BOOTSDI.IMG file. After that, it appears to hang while using the API to process a Calculate function! It never gets to the second RAM disk building iteration that normally follows and creates the final BOOTSDI.IMG output.

I'm baffled. Maybe the attached zipped copy of the complete log will offer you a clue.
 log.zip   532.91KB   378 downloads

[Lancelot]

I'm baffled.

Me too. We know this error at hostos-vistape builds but as far as i see your hostos is xpsp3.... Give some time please

edit: no this is not an error we know at hostos-vistape builds, need more time

[Arvy]

It's not consistent, not even in my own case, and such transient events are always the most difficult to pin down. We may never actually get to the bottom of it.

I hesitate to offer more input that may turn out (once again) to have no direct causal significance, but in cases like this, it's almost impossible to know what facts may be relevant. I'll mention, therefore, that this latest glitch occured during a run when the BootSDI.script itself installed IMdisk/AWEalloc onto the build platform. I then rebooted, leaving that installation in place and, thereafter, two subsequent BootSDI builds ran without any problem. Again, that may be purely coincidental.

Unfortunately, I didn't actually check MMC services during the problematic first run to ensure that the IMdisk service was actually running. But I would assume that it must have been because it did mount and dismount a RAM disk (as drive Z:) during its initial iteration. The hangup, whatever it is, appears to follow that initial dismount.

[Galapo]

I think now that various WB bugs that was forcing us still to use _Calculate calls (rather than WB internal functions) have been squashed we can use the WB internal functions to accomplish the same.

Regards,
Galapo.

[Arvy]

Sounds promising. If you'll post or PM whenever the revised version is ready, I'll try to check it out right away on this same platform. However, I can't promise a quick definitive response as I thought I had it licked once before.

[Lancelot]

Hi Arvy,

This is not much coincidental theory, but it is pure random

After your last post I remember this issue (which i first get randomly when testing with new Regfactory which uses imdisk ), but as you wrote it is very hard to pin down. One common thing about this issue is fresh installed imdisk, but this is not the only since i can not reproduce. (what is the second !! and what is the relation with calculate !!!), I wish fxscrpt was around since he probably have an idea. (I made mannnny manny trials to reproduce but could not)

Since i can not identify the issue, I can not put a warning on scripts !

there is a warning on bootsdihelp.rtf

so imdisk adviced , but may malfunction on first use in some scenerio, if this happens just restart your computer and make the build again.

but i admit this is not noticable (i wrote that part of the rtf but i also forget this issue sorry ).

Maybe using "WB internal functions" solves maybe not, it is hard to get the issue and even harder to get it reported on boot-land. Time will show .

[Galapo]

Sounds promising. If you'll post or PM whenever the revised version is ready, I'll try to check it out right away on this same platform. However, I can't promise a quick definitive response as I thought I had it licked once before.

I can probably only get to this after the weekend -- busy few days ahead with other things in life. If you have time yourself, there lines are already in the script and just have to be uncommented and then comment out the corresponding _calculate lines.

Regards,
Galapo.

[Arvy]

there is a warning on bootsdihelp.rtf but i admit this is not noticable (i wrote that part of the rtf but i also forget this issue sorry ).

Don't be sorry. It's impossible to anticipate every eventuality. In any case, I'm slightly doubtful about that being the root of the problem because, as mentioned, IMdisk did mount and dismount a RAM disk successfully prior to the hangup. However, as you say, it's very difficult to be certain of anything in these circumstances. IF it does turn out to be related, perhaps the warning could be incorporated into the pre-build project verification.

I can probably only get to this after the weekend -- busy few days ahead with other things in life. If you have time yourself, there lines are already in the script and just have to be uncommented and then comment out the corresponding _calculate lines.

Don't worry. Having other things to deal with seems to be a very common problem. Darn it! Unfortunately, I'm away from home right now myself and also somewhat constrained by other people's agendas, but I'll certainly do my best to try that and get back to you ASAP.

__
UPDATE: I've just had exactly the same problem on an identical build run on the same platform, but this time with IMdisk/AWEalloc already installed prior to the run. In the circumstances, I think we can say with reasonable certainty that the issue is not dependent on pre-existing availability (or otherwise) of the IMdisk service on any given platform. I'll report back as soon as I've had a chance to try Galapo's suggestion about using WB's built-in calculation capability in place of the Common_Api.script's version. Probably not until tomorrow evening.

For now, I can only report that it worked once on the same platform where the problem arose previously -- which proves nothing, of course, but it's none the less encouraging. At least it may indicate that some of those calculation "workarounds" are no longer needed with WB078sp4.

[Arvy]

As promised, here are my results using the same platform, the same WinBuilder (WB078sp4), and all of the same LiveXP scripts that I was using when the problems occurred. As noted above, the log seemed to indicate that the runtime hangup occured at a point where the BootSDI.script called the Common API (v15rev3) to carry out a _Calculate function which, in turn, uses sCalculate.exe and a temporary calc.txt file.

So, as suggested by Galapo, I modified the [Auto], [Optimized], [ImaFile] and [ImaFileTest] sections of the BootSDI.script (version 120) that are involved in ImgSize calculations. In each case the _Calculate "workaround" was commented out and the corresponding lines to use WB's built-in FOLDERSIZE, MULT, DIV and INC functions were restored.

Since making those changes, I have run four identical LiveXP builds -- two where IMdisk/AWEalloc was pre-installed and two where it was installed by the BootSDI.script. So far, there has been no recurrence of the problem. Because the problem was transient, that result is not actually conclusive proof of anything, of course, but I'll report here if it happens again.
__
P.S.: Just a passing thought FWIW, but it might be worth testing to see if a "silent hang" occurs in any script when there's a problem with the temporary calc.txt file output from the sCalculate.exe executable. Unfortunately, my own free time is severely limited right now.

[Galapo]

Hi Arvy,

That's good news. Please keep us informed if the behaviour reappears or otherwise.

P.S.: Just a passing thought FWIW, but it might be worth testing to see if a "silent hang" occurs in any script when there's a problem with the temporary calc.txt file output from the sCalculate.exe executable. Unfortunately, my own free time is severely limited right now.

At least for me, this is a bit hard to test as I've never had this hang occur.

Maybe you could try commenting this line from the api to test the calculate call that's not working in the BootSDI script. That is, revert to the hanging script, run it, and then when it hangs, see what the contents of calc.txt is.

//FileDelete,"%ProjectTemp%\calc.txt"

Regards,
Galapo.

[Arvy]

No problem. I didn't expect you to reproduce my own exact situation. Actually, what I had in mind was a "dummy" script that could call/run the Common API _Calculate function under a variety of test conditions -- with and without pre-existing calc.txt, sCalculate.exe files, etc. -- to see if it produced a "silent hang" in any case.

As matters stand, it appears fairly certain (as certain as one can be in the circumstances) that my hang up was occuring somewhere in the midst of that "workaround" function. I'm not quite certain whether it's getting stuck on the WebGetIfNotExist for sCalculate.exe or the following ShellExecute: [Hide] command. I'll try more experimentation later when I have more free time and report here if I can reach any more definite results. For now, I'm just happy that it hasn't recurred since I changed the BootSDI.script to use the built-in WB calculation and I'm able to get on with the job at hand.

[pscEx]

Mainly @Galapo:

I think that series of calculations into ONE output file calc.txt have the same timing / sharing / access issues we already have had with

• ShellExecute
  and subsequent
• FileDelete

(That has been the reason to generate the ShellExecuteDelete command.)

Why still in BootSDI _calculate is used?

IMHO since a while WinBuilder internal StrFormat functions can do the same tasks.

What cannot be done with StrFormat or is buggy processed?

Peter

[Arvy]

... timing / sharing / access issues ...

That certainly sounds plausible as the kind of situation that could arise at irregular intervals depending on a range of circumstances in any given case.

[pscEx]

For now, I'm just happy that it hasn't recurred since I changed the BootSDI.script to use the built-in WB calculation and I'm able to get on with the job at hand.

Some cross posting!
But I'm glad that your results also point to built-in functionality.

Peter

EDIT: Cross posting again!

The net is too slow ...

Peter

[Lancelot]

But I'm glad that your results also point to built-in functionality.

As written before, nobody can be sure

Why still in BootSDI _calculate is used?

History093=Galapo removed _Calculate calls in preference for native WB functions (so that 'Finalize Batch.Script' can be used)
..
History099=Galapo uncommented '_Calculate' lines in IMG size calculation due to bug with DIV command which will be fixed with WB078

I am not sure, maybe bug already fixed with wb077rc2 maybe not. It is hard for me to trace the development notes and since history notes taken to revertback with wb078...... and you know we are waiting for the new bugy free winbuilder