[HD2 General] MrT69:
Hmmmm... I'm not sure if I'm able to explain this right to an Senior Member. But let me try it ;)

O.k. letz go!

First at all, the rilphone.dll is not just only a simple stupid library, it's a core library because the rilphone.dll is the responsible RIL driver. Or within technical words, it's the communication layer between hard- and software.

The RIL Driver (Radio Interface Layer) is responsible for the communication between the hardware and software. Just to say it's a stupid DLL is from HTC is not the right description on it. ;)

Anyway, lets see what I have sort out.

On old CE devices the name for this layer dll was rilgsm.dll. I have checked the registry for entries of rilphone.dll and within the key

[HKEY_LOCAL_MACHING\Drivers\BuildIn]

DLL="rilphone.dll"

you will find the core entry. Next step - don't do it, just for explaination:

Rename the entrie "rilphone.dll" to "rilgsm.dll". I'm not sure if this dll is longer existing within WiMo but this is not important for the test.

If you disable this dll you only have nativ access to the hardware. Nothing within the Phone will work. No SIM, no GSM - nothing. Nijet. Nada.

BUT - and that's important, you will have access to core functions of the device also to the RTC (Real Time Clock). If you have had disabled this driver you will see that the phone start up and you will have the valid time and time zone.

Result:

RTC time is proper working which means that the communication between the provider and the device is working. NITZ (Network Identity and Time Zone) is working somehow because RTC is propper working

Move now again the DLL entry for the RIL back to default or do a factory reset. Now, you will see again that the SOFTWARE is not longer reading the RTC within the right way.

So - this result will cause 2 questions:

1. Why?

2. Who?

1. Question - WHY?

Based on Windows Mobile Developer FAQ there is no need to work with local TZI (Time Zone Informations) on the device because the will detected or generatet.

Basic API calls within Windows are responsible for the right Time and TZI. Now, again lets check WHY there is still a problem.

RTC is working, MS provides the API for get the right time but there is still problem.

Now let us check what interesting informations Microsoft is providing for the RILDRIVER:

O.k. - this is a good news. But for the HD2 a damn bad news.

If you investigate the boot process with an disassembler you will see that exactly this problem is related to the device. For some unknow reason one developer from Newseeland (!) has ignored this information:

"...code must not call

SetSystemTime

or

SetLocalTime

between the time that the RIL driver sends a RIL_NOTIFY_NITZ notification and the Windows..."

The RILPHONE.DLL send the RIL_NOTIFY_NITZ and this confuses windows, HTC AND the RTC entry.

2. Question - WHO is responsible?

Now we need to sort out the TZI or NITZ information issue. Related to the RIL driver issue it is normal that the NITZ is not proper working. We all know that there are 4 different option to the the right time:

1. RTC

2. RILDRIVER

3. HTC OS (so named SENSE)

4. Old PTP or PTPv2 and (?) NGN TimeSync via Provider

Lastly, my final consideration concerns to sort out the wrong timer.

Disable the RTC was not possible. O.K., if I would use a huge Hammer it might be a solution :)

RILDRIVER is a core element which must run. HTC OS could not be removed from the device and we all know the current and 3rd solution for all devices. Prevent the time trigger from the provider. But this solution sucks if you are traveling and you are not able to find the right button for it. To think about the problem that your GSM provider send the wrong time signal is more than stupid.

Must work within this way because other devices than HTC are working:

IF HRDWARE DEVICE == {{_HTC_Manufactor} Set_RANDOM_Time} Else

TriggerVALID _SetValidTime

Or the connection to the AtomTimeClock has latency of one to two hours... Ahhrrrgg...! It's bull**** at all!!

Can't hear that **** anymore...

I was investigating the registry for this device and I found two interesting keys:

[HKEY_LOCAL_MACHINE\Drivers\BuildIn]

DisableSyncTime=dword:00000001

and

[HKEY_LOCAL_MACHINE\Drivers\BuildIn]

NITZEnable=dword:00000001

I don't know anything about the "DisableSyncTime" because I have had nothing found about RIL_DisableSyncTime. May be there are more informations if you have the Devtools from Microsoft but there are no public related informations. Disable this option is not possible at all because this entry will set to dword:00000001 again if you boot up the device again. From this point of view it seems it's hard coded.

NITZEnable=dword:00000000

This entry was self spelling because of NITZ. If I prevent that the RIL LAYER to communicate the WRONG time to the device it MUST have the right time.

...BINGO!

Our good old Windows would normaly work with Framework to get the right NITZ information. Because of the Problem with the RILDRIVER it seems that this informations are not provided as it normaly should be.

From that point of view it was just a try and doing. I added the TZI values to the registry and windows is still accepting them. Cool...

This will finaly show that the rildriver (rilphone.dll) which is provided from HTC - NOT FROM MICROSOFT - causes the problem.

The RILNITZINFO contains this data:

typedef struct rilnitzinfo_tag

{

DWORD cbSize; = size

DWORD dwParams; = 7 (0x00000001|0x00000002|0x00000004)

DWORD dwNotificationCode; = 0x00000012 | RIL_NCLASS_MISC

Int TimeZoneOffsetMinutes; = -420 (28 quarters * 15 Minutes)

SYSTEMTIME SysTime; = 2004/07/23 13:39:20:00:000 (as SYSTEMTIME)

Int DaylightSavingOffestMinutes; = 60 (1 hour * 60 Minutes)

} RILNITZINFO, *LP RILNITZINFO;

From all this and based on my investigation on the current device and firmware I can say that the responsiblity for this fault is related to HTC. It's only smal code entry to prevent issues like that.

On the other hand, I guess it's hard to sort out or debug this because the developer can see this problem only on 2 day's during the year.

My patch is not a so named real solution, it's just a patch. But it's working on any device with the same problem until HTC has a running solution.

:)