Getting detailed version information of the executed program - windbg

Question

I'm trying to get the version information of the executable from a crash dump. It's not that simple, so please read the whole question before you come up with an answer that does not work.
lm vm appname
Basically I can do lmv to get the version details, and that is exactly the information I want.
If you don't know how to get the version information of the executable, you can google a bit and get this answer, which suggests
lm vm appname (without .exe)
This works probably in 90% of the cases. However, it has the following two issues which I want to resolve in an automated analysis:
What is appname if I don't know the executable in advance?
In special cases like Notepad++, the module name is not notepad++ but rather notepad__
Now I can find out the executable name using |, but extracting the name of the executable from that output is not trivial.
Finding the exe in the list of modules
It is possible to find executables in the list of modules with a command like
.shell -ci "lmf" findstr "\.exe"
We can then extract the address and list the details with
.foreach /ps 9999 (exe {.shell -ci "lmf" findstr "\.exe"}) {lmva exe}
Still, there is a problem: .NET processes can load assemblies that are not DLLs but EXEs. In that case, the output might be wrong if the first result is not the main executable but a EXE loaded later.
List of modules
It is possible to get a list of modules using lm1m. And usually, the first one in that list is the executable.
It is then possible to extract the first line and get the details for it. A command looks like
.foreach /ps 9999 (exe {lm1m}) { lm vm ${exe}}
Unfortunately, it is not guaranteed that the executable is the first module. The modules are sorted by address. And IMHO it might happen that the executable is loaded at a higher address.
Question
How do I get lmv information for the main executable reliably.
Assumptions that can be made:
user mode crash dump of type /ma
only one process is being debugged

Answer 1

As mentioned in the comments by Jeroen Mostert, a suitable command might be
lmv a $exentry
This works, because lm is smart enough to accept address which are within a module. $exentry gives the entry point of the first executable.
You find the description in the pseudo register syntax:
$exentry: The address of the entry point of the first executable of the current process.
[Source: WinDbg help]
For the C# part, we can use the following piece of code for testing:
using System;
using System.IO;
using System.Reflection;
namespace exentry
{
class Program
{
static void Main()
{
var fullExe = Assembly.GetEntryAssembly().Location;
var path = Path.GetDirectoryName(fullExe);
var newexe = Path.Combine(path, "exentry2.exe");
File.Copy(fullExe, newexe);
Assembly.LoadFrom(newexe);
Console.WriteLine("Debug now");
Console.ReadLine();
}
}
}