[Windows Mobile] tobbbie:
Provxml sequence: 1.) mxipcold*, 2.) mxip_* 3.) mxipupdate

Another find - please validate with your setup (I am still on 1.3.187 - as only WM7 gets updates naturally. It would be good to see in the changelog if also WM6.x would profit from a listed update):

The OSB tool "Provxml Files" gives an overview about the guessed sequence of provxml execution derived form the packages.sof definition. Sadly I noticed that something must go wrong here as consistently the things I had defined in a late package was overwritten by something in an earlier one.

You know that there are not many methods to debug this early phase of boot when the provxml execute, so I supplied a dedicated trace at the end of each provxml:

<!-- trace execution begin
*** change the [B][COLOR=Red]<filename>[/COLOR][/B].traced below to the name of
*** the .provxml where you copy this at the end.
Purpose: Utilize the creation of a shortcut
to get a system timestamped artifact in the context
of the current provxml execution.
After Cold Boot (Hard Reset), you can sort the
directory \Windows\ProvXml\ by file date and
you have the sequence of .provxml execution listed.
-->
<characteristic type="FileOperation">
<characteristic type="%CE2%\ProvXmlTrace" translation="install">
<characteristic type="MakeDir" />
<characteristic type="[COLOR=Red][B]mxipupdate_windowslive_1[/B][/COLOR].traced" translation="install">
<characteristic type="Shortcut">
<parm name="Source" value="%CE2%\solitare.exe" translation="install"/>
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<!-- end of trace activity -->

Result was that from all executed provxml (their names were timestamped traced in the \windows\ProvXmlTrace directory) the sequence is this:

all mxipcold* in the relative sequence of their packages.sof

mxip_* others (also mxip_cold_* which is something that the HtcInit may care about later) in the relative sequence of their packages.sof

all mxipupdate* in the relative sequence of their packages.sof

I could definitely prove that the sequence given in the provxml preview of the OSB is not the one which is executed. Mind that the name of the package in the name of the provxml file is the reason to pick it like above, not the directory it is stored in! So no matter where you store the *.provxml in your kitchen path, it is only the name and the highest priority match it has for execution above.

I noticed this because I had a file "mxipcold_smartfon_TB.provxml" put last in the sequence row of my packages (some Z_OEM_my settings), also had the *.DSM set correctly and likewise the packages.sof definition. However there was also a file "mxipcold_smartfon_1.provxml" which was part of the \SYS\CommonNonEA package and this was further up the list in packages.sof. Still it was not at the top of the list, where only other mxip_* and mxipupdate packages were located. So for sure it is that first come all mxipcold*, then all mxip_* and finally all mxipupdate packages. It is also sure that mxip*<packagename>*.provxml will be executed at highest place in priority no matter by which <guid>.dsm in the packages.sof it has been elevated there.

You must note that HTC (others maybe as well) have an additional method to initialize the device. You may find a driver "htcinit.dll" in the OEM drivers section which will then call a "HtcColdBoot.exe". This may have additional capabilities and put the mxip*.provxml in possibly another sequence.

Since this is part of the OEM and the native Windows mobile has their own coldboot treatment (via coldinit.exe) their worksplit and alignment requires dedicated attention if you want to keep the OEM part.

Above findings come from the pure Windows Mobile treatment (i.e. without htcinit.dll driver).

You can trace sequence with above listed method in your own environment. Ultimately this (or similar) trace-method could be automated in the tool section of OSB as the manual editing of your provxml files is a little annoying - permission granted :-)