Search the Community

I am looking for a way to retrieve filtered messages from the ‘system debug channel.' also known as ‘kernel-mode debug output.' AutoIt must do the capture in real time. The following AutoIt UDF almost does what is required but it only captures application level, or Win32 debug output. https://www.autoitscript.com/forum/topic/82889-capture-debug-information-udf/#comment-593268 The utility DebugView by Sysinternals captures the information as required by turning on Capture Kernal and in my case using the Filter include: *Incoming connection* The use of DebugView to do this is covered in the following tech note; https://www.tacticalsoftware.com/support/tech-notes/logging-com-port-activity.htm https://technet.microsoft.com/en-us/sysinternals/debugview.aspx However to make to make the information from DebugView available to my AutoIt script required DebugView capture to a text file and then my AutoIt script monitor that file for changes. The use of DebugView to capture the system debug channel could be made to work, but it was less than reliable and difficult to get started. The startup wasn’t something that could be easily automated not even with AutoIt. If you understood what I am talking about and made it this far, I think an explanation of the application is in order. Lots of details here sorry trying to answer questions in advance. I support a large installation of General Electric MUSE application. MUSE is a Windows-based medical application that processes and archives ECGs (electrocardiograms) taken on dedicated hardware (ECG Carts). Several methods exist on the cart to get the ECG from the Carts to the MUSE system; they range from floppies (on old obsolete hardware), memory cards, RS232 serial ports, and hardwired network connections. In our installation, we choose not to use the vendor-supplied network solution due to a variety of reasons I won’t get into here. Instead, we have designed our own connection solution. We use a wireless serial server mounted on the ECG carts connecting to a server running a Serial/IP COM Port Redirector. The ECG cart and MUSE application think they are talking to each other via an RS232 port and as far as they are concerned, they are. However, this RS232 cable happens to run through our province (think State) wide Health Care WAN. The hardware and software used can be seen on these two sites; http://www.bb-elec.com/Products/Wireless-Cellular/AirborneM2M-802-11-a-b-g-n-Dual-Band-Wireless/AirborneM2M-Industrial-Dual-Band-Wi-Fi-Router-Brid.aspx https://www.tacticalsoftware.com/virtual-serial-port-redirector/serial-ip.htm This setup works well we have over 130 ECG carts connecting using this setup. However, the end users are not technical, and there is a lot that can go wrong with wireless connections. So we do get complaints, often after the fact, that the ECG cart would not connect. A log of what ECG carts connected and when would be very helpful. The Serial redirector software can be configured to log all activity to the Kernal-mode Debug output. The serial redirector software itself being kernel level software. For configuration of the Wireless modules, we have custom written software (written in AutoIt) that amongst other things can display relevant configuration information for a Wireless module given it’s IP address. By extracting messages like the ones below from the Kernal-Mode Debug channel; COM56 : ½ Incoming connection from 10.158.188.172:51562 COM18 : ½ Incoming connection from 10.158.188.200:50896 COM19 : ½ Incoming connection from 10.158.188.180:59074 COM68 : ½ Incoming connection from 142.239.15.82:34322 We can have the module configuration program retrieve the configuration. The retrieved configuration contains more information such as the module ID number and wireless signal strength. This information is then logged to a file which is later loaded into a database. We can then query the database for connections made by a particular module within a specified time frame. The results of these Queries help us determine if the module was connected or is having problems connecting. Problems are usually indicated by poor signal strength and frequent re-connecting. So what I am looking for is a way for our module configuration program (written in AutoIt) to retrieve filtered Kernal-Level debug messages directly without using the DebugView application. The Forum post listed at the first of this message includes the source code for the DLL. So if you are versed in these matters and Visual Studio this may be an easy task. I looked at what needed to be done but, I was way over my head. If you look up the price of the serial IP redirector software, you can see that there is some money in our project for such things however, I do have a spending limit for purchases such as this.