To All:
What is needed is reverse thing for DebugService ( as described here: http://alter.org.ua/docs/nt_kernel/kdprint/) : KdpTrap is called to print (store?) debug message somewhere, what is needed, is something that will extract back stored messages. dmesg patch successfully stores debug messages in buffer, some kernel code should give them back.
Roughly speaking needed the piece of DeviceIOControl that copies memory from kernel mode to back to user mode.
Any help is welcomed!
***
Returning to discussion with dmex:
What I'm speaking is totally different.
it can write to the bootlog file and ETW for the Event Log. user-mode tools like Winbdg, dbgview, Event Viewer, notepad.
All these things require stable working user-mode code, perfectly booted up kernel, etc.
To get there is is needed to debug the kernel. If you haven't serial cable, or have, but your machine hasn't COM-port, as in my case, then you have no other choice to use my dmesg command in kdbg - ROS kernel debugger.
After corrections your machine is booted up. Now you'd just want to look on these debug messages stored in DmesgBuffer: to review it, to review found bugs, quirks, at last to mail it somewhere, say into bugzilla. Or compare working installation with not working one - the effective way! This trick has helped me many times.
After that it could use whatever whistles you want: Winbdg, dbgview, Event Viewer, notepad, notepad++, notepad+=10 etc. But! At start, working system is needed. It could even have 'OutputDebugString' interface. I didn't ever say this should be the only one implementation. I just want tools to help booting up the ROS. not more. _but not less_.
But you are looking only of perspective of fully functional Windows. That is not the case with ROS.
DebugPrint uses OutputDebugString.
No, no! just the opposite, look at calls hierarchy tables at http://alter.org.ua/docs/nt_kernel/kdprint/
OutputDebugString is user-mode code. If you have user-mode perfectly working - you use dbgviews and you need nothing more. All is working already at that moment.
***
Best regards, M.A.
On Tue, Apr 12, 2011 at 9:49 PM, dmex dmex04@gmail.com wrote:
Please point me the same thing. Two or three implementations.
Windows uses the screen, COM1, DBWIN_BUFFER, WMI and ETW to write trace output during/after boot to various locations. Starting with Windows Vista, WMI creates an active trace channel during the boot process which is allot more effective than dmesg so I would look at evntrace.h. Only errors are logged. Windows later writes to COM1 once the driver loads, WMI is implemented in the kernel and (should be loaded) very early into the boot process.
At points before these services are available (I.E. NTLDR) Windows writes output to the console or does a KeBugCheck, then later to WMI/ETW, COM1, then DBWIN_BUFFER in that order. I would prefer output to the screen as much as possible until these services are up and it can write to the bootlog file and ETW for the Event Log.
What compartability did you mean?
How do you propose someone obtain these messages during and after boot without writing new tools? Since the goal of ROS is more or less compatibility, not all devs coming from Windows would expect something like that to be holding trace/debug output. I can use windbg, dbgview, event viewer and ETW log files to view this stuff on Windows so why implement something else completely different for ROS? The goal should be increased compatibility with Windows, not less.
Any bugs, errors occurred during that process of printing into that
MappedView associated with "DBWIN_BUFFER" FileMapping are reported to kernel with DbgPrint.
Where should these errors be stored?
DebugPrint uses OutputDebugString.
Linux in past has such shared memory object, but practically, now, it is
overridden by the system call.
So my question remains Subject: Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
From user-mode to kernel, My advice would be anything that lets me use existing user-mode tools like Winbdg, dbgview, Event Viewer, notepad.