Thursday, 13 February 2014

GDR, LDR, QFE Explained

I was trying to install a particular version of CLR on my Windows 8 VM via MS security updates, and they used some terms like GDR and LDR there without proper explanation. Let's see an example.

​(From http://support.microsoft.com/kb/2833958 )

File information

GDR Service Branch
Collapse this tableExpand this table
File nameFile versionFile sizeDateTime
Mscorlib.resources.dll4.0.30319.180101,038,85631-Aug-201200:52
Mscorlib.resources.dll4.0.30319.18010984,58431-Aug-201200:51

..........

LDR Service Branch
Collapse this tableExpand this table
File nameFile versionFile sizeDateTime
Mscorlib.resources.dll4.0.30319.190101,038,85631-Aug-201200:53
Mscorlib.resources.dll4.0.30319.19010984,58431-Aug-201200:52
..........

​The file version I was looking for ​was in GDR Service Branch, but I was still not sure if I would get the expected version installed correctly on the machine. Before trying, I needed to understand what they meant. 

​​So, what are they?

First of all, the terms stand for: 

  • GDR means "General Distribution Release". 
  • LDR means "Limited Distribution Release". 
  • QFE means "Quick Fix Engineering" which is deprecated by LDR now.

GDR versions are intensively tested but do not contain many fixes as LDR versions. LDR versions are not fully tested just like our hot fixes. All distributed versions are, of course, basically GDR. Then, how the system gets into LDR mode? Let me quote another comment from the references. 

A package delivered by Windows Update contains both GDR and LDR versions of the files it updates, so that it is able to replace the files on the system regardless of which branch they are currently on.

A package acquired outside of Windows Update contains only LDR versions of the files it updates, and this will "move" the files onto the LDR branch where they will remain until the next Service Pack.

​​This means, if we just use Windows Updates all the time, the system never gets chance to switch. However, once an LDR-only hot fixes is applied, the system will be regarded as LDR. 

​How do we know the current status?

The information can be retrieved on PowerShell. 

PS> Get-item c:\Windows\System32\ntoskrnl.exe | select *


"FileVersion" field shows the branch name. On this screenshot, it's GDR. So if I install the fix package on the KB article I mentioned first, the system will get the GDR version of file which I want. 

The following table from a Windows KB can be also used for determination.


VersionProductMilestoneService branch
6.0.6000.16xxxWindows VistaRTMGDR
6.0.6000.20xxxWindows VistaRTMLDR
6.0.6001.18xxxWindows Vista SP1 and Windows Server 2008 SP1SP1GDR
6.0.6001.22xxxWindows Vista SP1 and Windows Server 2008 SP1SP1LDR
6.0.6002.18xxxWindows Vista SP2 and Windows Server 2008 SP2SP2GDR
6.0.6002.22xxxWindows Vista SP2 and Windows Server 2008 SP2SP2LDR


​References


Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Monday, 6 January 2014

TILog.exe crashes with System.BadImageFormatException, after a unit test started

When performing unit tests from Visual Studio 2010, I got this strange error.


What is TILOG.EXE?

This is "Microsoft Visual Studio Logger". It seems that this utility is called by Visual Studio and acts as a logger for the tests. I got this help message from another machine.


What was the actual error?


"Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'TiLog.exe' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."

Does it sound reasonable? Maybe not, but it turned out that it didn't lie. See the next section.

How to fix the problem
  1. Open up C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\DataCollectors\TILog.exe.config using your favourite editor. It should be something like this: 
    • <?xml version="1.0" encoding="utf-8" ?>
    • <configuration>
    •   <startup>
    •     <supportedRuntime version="v4.0.40219" />
    •     <supportedRuntime version="v2.0.50727" />
    •   </startup>
    •   <runtime>
    •     <generatePublisherEvidence enabled="false"/>
    •   </runtime>
    • </configuration>
    • See the version there - v4.0.40219. Is it correct? Probably not. I checked my system to see if my machine has .Net 4.0.40219 and the version it had was 4.0.30319. Actually, it seemed that the number "40219" was from the TILOG.exe itself! See the 2nd screenshot above - the version was 10.0.40219.1. 
  2. So I added a new line to have a correct version on it. 
    •     <supportedRuntime version="v4.0.40219" />
    •     <supportedRuntime version="v4.0.30319" />
    •     <supportedRuntime version="v2.0.50727" />
    • It's up to you to completely remove the first line or keep it. 
  3. Run TiLog.exe from command prompt or restart your unit test. 
Sent from Evernote

Monday, 9 December 2013

Free e-book: Object-Oriented Programming with ANSI-C

This interesting book written by Axel Schreiner has some answers about the possibility of OOP in plain C. Although we're continuously moving to managed languages mainly based on Java or .Net, it's still worthwhile to take a look at this book to understand OOP concepts better and get fresh new ideas for the future. 

( Image from www.cs.rit.deu/~ats/ )



Sent from Evernote

Wednesday, 4 December 2013

How to solve exception on loading of Microsoft.Practices.EnterpriseLibrary.Logging for WPF application development

Today I got an exception from Visual Studio 2010 which complained the unresolvable module of Microsoft.Practices.EnterpriseLibrary.Logging (version 2.0.0.0, Public Key 13aaee2494f61799) when I attempted to open a XAML UI developed by others. To my embarrassment, this .Net DLL is already GAC-ed on my machine. Probably, one or more of its satellite libraries were missing. 


It's turned out that I should install "Enterprise Library for .Net Framework 2.0". The exception is now gone after installing the library package and restarting VS. 

Interestingly, even without the Enterprise Library, I was still able to compile & run the project. It means that the missing part matters on design time only. 

Sent from Evernote

Can't reboot Optimus G Pro into recovery mode after installing CyanogenMod 10.2

Yesterday, I encountered a strange problem to update the CM10.2 RC ROM to the official CM10.2 on my E986 as I couldn't make the phone boot into recovery mode. It just showed this disappointing message. 


Actually it was obvious that I succeeded in doing that - or I wouldn't be able to install CM 10.2 RC. So what happened? As I am not an expert in this area so that I am not 100% sure, but it seems that the last recovery image to apply CM 10.2 RC was not fully compatible with my e986. 

(Warning - Everything is at your own risk!)

Last time, I used 2nd-init recovery to inject CWM and it worked with no issue so I still don't understand why not now. Anyway, I was advised that I should use a loki-compatible recovery tool. e.g. FreeGee. (What is loki??? Don't ask me, please!) Interestingly, I found that several people encountered the same problem of mine and some of them just reverted the ROM back to the stock one and start from scratch with safer tools. I know it could be the best, but I didn't have the stock ROM.

Instead, I installed FreeGee I mentioned above. Unfortunately, the latest version (1.9.5) didn't do anything but displaying "Error 127" so I googled to find an older one and finally found Chinese version of 1.2.4 which worked fine whilst I don't speak Chinese. FreeGee has a few options to take various recoveries and I used CWM. I won't link that Chinese version here as I believe the developer of FreeGee will fix the current problem soon and that unsecured version I used might brick your machine. 

Therefore, if you encounter the same problem, use FreeGee! 
Sent from Evernote