“A powerful feature of Visual Studio .NET is its ability to debug across languages that target the common language runtime, and across execution environments. For example, if you write a Visual Basic .NET component that is called by a C# component that is in turn called by COBOL code (that targets the runtime), you can seamlessly step between languages when debugging. You can also see a single callstack that shows the different functions called in the languages you just stepped through.” Read the rest of the article at MSDN. “A good understanding of the Portable Executable (PE) file format leads to a good understanding of the operating system. If you know what’s in your DLLs and EXEs, you’ll be a more knowledgeable programmer. This article, the first of a two-part series, looks at the changes to the PE format that have occurred over the last few years, along with an overview of the format itself. After this update, the author discusses how the PE format fits into applications written for .NET, PE file sections, RVAs, the DataDirectory, and the importing of functions. An appendix includes lists of the relevant image header structures and their descriptions.” Read the rest of the article at MSDN.
Debugging in Visual Studio .NET & Understanding PE
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Let’s see your Java (runtime) debugger do that
I’ve been looking for something like this for a while. Why I didn’t just go straight to the source (MS) is beyond me.
I’ve already learned more about the PE obj file format in the apst 10 minutes of reading than years of using and administering windows. Woohoo! I just finished reading the spec for the ELF file format recently and this will be an interesting comparison.
On a side note – Did I see mention of Cobol? What kind of a sick joke is this?
TaCo – I hope you have your body armour on.
Using Opera those links make little sense…
it’s all nice and sweet, but if you ever used gcc, nasm or even gas, you have the ability to do the same. Just give the ‘-g’ option to the command line and your nice ELF got all the debugging information of their native language. You can then use gdb to transparently debug between all the various languages you used to create your application, be it between asm, C, C++, Java, or any other language supported by the gnu-compiler tools.
About time Microsoft wakes up, but if you ask me, they shouldn’t get the crown, such stuff has been around for far much longer on about any other platform.
Can you debug a remote server from a local machine in code called from JScript that invokes a Java object when in turn invokes a C++ class that calls into a system C lib and fails somewhere down in the system drawing code, tracing the entire stack, and memory using gcc/xxgdb?
I’ve never tried something like this in Unix, but it is quite easy to do in VisualStudio.net. You can also debug several processes simultaneously using the same debugger, and even remote machines. This is very useful in the case that you have a .NET client and a .NET server (remote) that you are debugging at the same time.
we use PE as the core format for the whole of Petros including kernel and drivers. I’ve been aware of the original docs and the NT header files and use them to refer to stuff. Still, there are gaps and stuff that you have acquire through other methods. For e.g. the PE checksum is not documented as far as I know, and this may be important for writing NT drivers – I’ve nver checked. Also, thread local storage and use of the FS register while documented to some level in other articles has always been pretty much hit & miss. The other bit which is hard to glean is structured error handling – even despite a later article from MSDN on the subject. There are probably a few other areas, but it does make an OS developer’s and a compiler writer’s job “fun” to say the least. This first article hints at a few enhancements to PE format but didn’t tell me much beyond what was there before.
I am also puzzled over one section regarding the explicit DLL references to the compiler and the code it generates. The reason for the DLL jump table is not just a linker necessity, it is also a result of the DLL patch structures only having a single address which can be patched. If there are many CALL [XXXXXXXX] referencesto the same procedure in the executable, how can they all be patched if there is only one patch reference per function?
P
disregard my last question. The indirect reference is always to the import table which will be patched so it’s not a problem. I think I was confused because the jump table ended up being patched with some compilers.
There is a way it could be done if the calls are of the form CALL XXXXXXXX
The linker could point to the first DLL call, and then follow a linked list patching each as it went – this is how things were done on other older minicomputer OSes I have worked on. The disadvantage with this is that the DLL load time becomes O(N^2) instead of O(N) or O(NlogN) (you can do a binary search on the export list as it’s alphabetically sorted)
P