|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ReflectionI am trying to develop an easy way to manage dll load addresses for my .NET
controls and libraries. I was wondering if through reflection or some other type of mechanism in .NET that I could examine the compiled dll to determine what its base load address is and its size? With that information I could create a visual map to use to organize my dll's and ensure they all play nicely. Thanks... Lee wrote:
> I am trying to develop an easy way to manage dll load addresses for my .NET Read the PE /COFF file format specification:> controls and libraries. I was wondering if through reflection or some other > type of mechanism in .NET that I could examine the compiled dll to determine > what its base load address is and its size? With that information I could > create a visual map to use to organize my dll's and ensure they all play > nicely. http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx The format isn't too hard to work with. A set of indirections will get you to where you want to go. For example, at offset 0x3C into the file, there is the offset to the Signature (PE\0\0) followed immediately by the PE / COFF File Header, which is 20 bytes long. In .EXEs and .DLLs, it's immediately followed by the Optional header. The Optional Header has different magic (first word) (0x10B or 0x20B) depending on 32-bit (PE32) or 64-bit (PE32+) image. At offset 28 (PE32) or offset 24 (PE32+) is the image base, which is 4 bytes in PE32 and 8 bytes in PE32+. You should be able to make a combination of FileStream and BinaryReader read this. -- Barry Barry Kelly wrote:
Show quote > Lee wrote: However, I should point out that if you want accurate representations of> > > I am trying to develop an easy way to manage dll load addresses for my .NET > > controls and libraries. I was wondering if through reflection or some other > > type of mechanism in .NET that I could examine the compiled dll to determine > > what its base load address is and its size? With that information I could > > create a visual map to use to organize my dll's and ensure they all play > > nicely. > > Read the PE /COFF file format specification: > > http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx > You should be able to make a combination of FileStream and BinaryReader > read this. the total virtual memory usage, you're going to have to iterate through the image sections and check their RVAs and sizes. -- Barry yo.
Show quote "Lee" <L**@discussions.microsoft.com> ë‹˜ì´ ë‹¤ìŒ ë©”ì‹œì§€ë¥¼ 작성했습니다. news:6178961F-DCFF-4CF8-A77E-EBF2ED1A3BDE@microsoft.com... >I am trying to develop an easy way to manage dll load addresses for my .NET > controls and libraries. I was wondering if through reflection or some > other > type of mechanism in .NET that I could examine the compiled dll to > determine > what its base load address is and its size? With that information I could > create a visual map to use to organize my dll's and ensure they all play > nicely. > > Thanks... "Lee" <L**@discussions.microsoft.com> wrote in message ..NET dlls don't have load addresses, because they don't contain compiled news:6178961F-DCFF-4CF8-A77E-EBF2ED1A3BDE@microsoft.com... >I am trying to develop an easy way to manage dll load addresses for my .NET > controls and libraries. I was wondering if through reflection or some > other > type of mechanism in .NET that I could examine the compiled dll to > determine > what its base load address is and its size? With that information I could > create a visual map to use to organize my dll's and ensure they all play > nicely. code. The JIT reads the MSIL from the assembly, compiles it, linking dynamically so there's no need for fixups, and write the compiled code out (sequentially?) somewhere in memory. The size isn't known, and may vary from run to run depending on whether all code paths are accessed. C++/CLI mixed assemblies are a different story. Like native dlls, they do have compiled code that needs fixups if there is a base load address conflict. Show quote > > Thanks...
Show quote
On Mon, 12 Mar 2007 14:49:36 -0500, "Ben Voigt" <rbv@nospam.nospam> Sorry, they do. See /baseaddress option for the C# compiler. It'swrote: > >"Lee" <L**@discussions.microsoft.com> wrote in message >news:6178961F-DCFF-4CF8-A77E-EBF2ED1A3BDE@microsoft.com... >>I am trying to develop an easy way to manage dll load addresses for my .NET >> controls and libraries. I was wondering if through reflection or some >> other >> type of mechanism in .NET that I could examine the compiled dll to >> determine >> what its base load address is and its size? With that information I could >> create a visual map to use to organize my dll's and ensure they all play >> nicely. > >.NET dlls don't have load addresses, because they don't contain compiled >code. The JIT reads the MSIL from the assembly, compiles it, linking >dynamically so there's no need for fixups, and write the compiled code out >(sequentially?) somewhere in memory. The size isn't known, and may vary >from run to run depending on whether all code paths are accessed. usually only important for NGEN'd assemblies. See http://msdn.microsoft.com/msdnmag/issues/06/05/clrinsideout/default.aspx#S4 Austin <snip>
Show quote
"Austin Ehlers" <austin.ehlers.spam.@gmail.com> wrote in message Yes, you're right. In essence, ngen converts a pure MSIL assembly such as news:2qhbv25oqgk6ed5o3ptkc8bgjetehef1hq@4ax.com... > On Mon, 12 Mar 2007 14:49:36 -0500, "Ben Voigt" <rbv@nospam.nospam> > wrote: > >> >>"Lee" <L**@discussions.microsoft.com> wrote in message >>news:6178961F-DCFF-4CF8-A77E-EBF2ED1A3BDE@microsoft.com... >>>I am trying to develop an easy way to manage dll load addresses for my >>>.NET >>> controls and libraries. I was wondering if through reflection or some >>> other >>> type of mechanism in .NET that I could examine the compiled dll to >>> determine >>> what its base load address is and its size? With that information I >>> could >>> create a visual map to use to organize my dll's and ensure they all play >>> nicely. >> >>.NET dlls don't have load addresses, because they don't contain compiled >>code. The JIT reads the MSIL from the assembly, compiles it, linking >>dynamically so there's no need for fixups, and write the compiled code out >>(sequentially?) somewhere in memory. The size isn't known, and may vary >>from run to run depending on whether all code paths are accessed. > > Sorry, they do. See /baseaddress option for the C# compiler. It's > usually only important for NGEN'd assemblies. See > http://msdn.microsoft.com/msdnmag/issues/06/05/clrinsideout/default.aspx#S4 C# generates, into a mixed assembly, and so load addresses and fixups become important again. I think I did make mention of mixed assemblies, thanks for pointing out that they aren't necessarily C++/CLI when ngen is used. Show quote > > Austin > <snip> "Lee" <L**@discussions.microsoft.com> wrote in message For example, SymGetModuleInfo64 and SymEnumerateModules64news:6178961F-DCFF-4CF8-A77E-EBF2ED1A3BDE@microsoft.com... >I am trying to develop an easy way to manage dll load addresses for my .NET > controls and libraries. I was wondering if through reflection or some > other > type of mechanism in .NET that I could examine the compiled dll to > determine > what its base load address is and its size? With that information I could > create a visual map to use to organize my dll's and ensure they all play > nicely. Details at http://msdn2.microsoft.com/en-us/library/ms681408.aspx Show quote > > Thanks...  |
|||||||||||||||||||||||
Other interesting topics