How to get the CPU Temperature info from Bios using c# I gave a try to the code in CPU temperature monitoring
But no luck. enumerator.Current threw an exception.
How can i achieve this ? Thanks.
Error :
"This system doesn't support the required WMI objects(1) - check the exception file
Not supported
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
at CedarLogic.WmiLib.SystemStatistics.RefreshReadings() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 25
at CedarLogic.WmiLib.SystemStatistics.get_CurrentTemperature() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 87
at TemperatureMonitor.SystemTrayService.CheckSupport() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\TemperatureMonitor\SystemTrayService.cs:line 260"
Have a look at OpenHardwareMonitor.
I'm having the exact same problem:
https://superuser.com/questions/183282/cant-query-cpu-temperature-msacpi-thermalzonetemperature-on-windows-embedded-7
The code in the link you cited is correct. My .exe works fine on Windows/XP and Windows/Vista (as long as I "run as Administrator" on Vista) ... but fails with the WMI error "not supported" on Windows Embedded 7.
At this point, I don't know if the problem is the OS (WES7) or my motherboard (an Intel DH57jg).
Although not ideal, the closest/best solution I have found is to use Speedfan (free), which can expose its probe information to external applications, via a memory-map. Somebody has done the C# conversion:
Reading SpeedFan shared memory with C#
"Building on what I spoke about in my
previous post, lets say we want to
access the data that SpeedFan provides
from a C# application. As a small
aside, reading information from the
SMBus and other low level interfaces
can only be done from the kernel. So
applications like SpeedFan (HWMonitor,
Everest, etc etc) generally run a
driver at kernel level and then a
front-end GUI to present the
information.
In the case of SpeedFan, shared memory
(actually its technically a memory
mapped file on Windows I think) is
used to communicate between the kernel
driver and the userspace GUI
application. Even better, the format
of this file has been made public by
the author of SpeedFan. So, enough
talk, lets see some code!"
Related
I've a program where argv[0] gets overwritten from time to time. This happens (only) on a production machine which I cannot access and where I cannot use a debugger. In order to find the origin of this corruption, I'd like to write protect this stack page, so that any write access would be turned in a fault, and I could get the address of the culprit instruction.
The system is an AIX 5.3 64 bits based. When I try to invoke mprotect on my stack page, I get an ENOMEM error. I'm using gcc to generate my program.
On a Linux system (x86 based) I can set a similar protection using mprotect without trouble.
Is there any way to achieve this on AIX. Or is this a hopeless attempt?
On AIX, mprotect() requires that requested pages be shared memory or memory mapped files only. On AIX 6.1 and later, you can extend this to the text region, shared libraries, etc, with the MPROTECT_TXT environment variable.
You can however use the -qstackprotect option on XLC 11/AIX 6.1TL4 and later. "Stack Smashing Protection" is designed to protect against exactly the situation you're describing.
On AIX 5.3, my only suggestion would be to look into building with a toolset like Parasoft's Insure++. It would locate errant writes to your stack at runtime. It's pretty much the best (and now only) tool in the business for AIX development. We use it in house and its invaluable when you need it.
For the record, a workaround for this problem is to move processing over to a pthread thread. On AIX, pthread thread stacks live in the data segment which can be mprotected (as opposed to the primordial thread, which cannot be mprotected). This is the way the JVM (OpenJDK) on AIX implements stack guards.
I'm trying to build a virtual printer.
There are already some answers like this and this.
However my demand is more specific. I just want to create a virtual printer that can be added into the system and can be accessed from any application. On clicking print command, a dialog looks like a real printer pops out and generates a PDF on printing. Then some more actions, like pushing the PDF to my server, are performed.
Do I need to dig into Windows Driver Kit? Or is there any free SDK for this?
Thanks.
Not sure if this question is still relevant to you, but you'd probably want to think about something like this:
Use the WDK (Windows Driver Kit) to create a Unidrv UI plugin. This will allow you to specify UI during the print (for your printer dialogue). The reason why you'd want to show UI here is because it's one of the only printer driver components that runs in the user session (the same process as the printing application). The XPS pipeline and port monitor are both session 0.
If you want to stick to MS convention, you'll do the spool file to PDF conversion in the render filter of the XPS Filter pipeline (this is if you're using an XPSDrv driver). The filter pipeline is where you have the opportunity to modify the XPS spool data coming in and in the final filter, convert it to your output document type (PDF in your case).
To do post print processing, you might want to consider creating a port monitor (again with the WDK) and kicking off a new process to do the post print processing after the port monitor writes out the print output to disk.
Only problem with this approach is that you can't use port monitors in Version 4 drivers (this is the new type of driver in Windows 8). Version 3 drivers still work in Win 8, but I guess they'll be phased out eventually.
Sorry it's probably not very obvious, but as I say, it's a high level overview (and unfortunately driver development is still very complex beyond a simple print to file). Version 4 printer drivers are becoming a lot easier to develop, but unfortunately with the removal of port monitor support and other improvements, it makes it a lot harder to develop anything requiring post processing.
[DISCLAIMER: I'm associated with the Mako SDK R&D team]
I know you asked for a free SDK, unfortunately I don't know of anything that would be suitable, but I know our company offer a Virtual Printer Platform (SDK) which would be good for you (prints to PDF and supports post print processing). You can find more information at the Mako SDK website
Hope this helps a bit anyway. I know printer driver development can be very confusing at times!
After reading up and doing a lot of research, with the aim to setup up something like redmon and use the printer SDK, I have completed the project using this SDK: http://www.novapdf.com/pdf-sdk.html
This solution however will work with windows only.
[I am not affiliated with novaPDF]
I have investigated an OSX version, however this will be a different build, you can probably set something up using this method: http://www.jms1.net/osx-pdf-services.shtml [I have not yet tried this]
i have a device (cash drawer) and i would like to directly communicate with the device. I know that its on address f1. Also openbit is 01.
As i've understood so far, i'd need to send 1 to memory address f1 and the cash drawer should open. Though using asm, i get access violation. Then again i've read that windows does not let you communicate directly to device i/o addresses (need to use win). What would be the correct way to send the data to that address.
Note that i cannot use drivers, because i can't communicate with the driver inside my application.
Op. system is win7.
Thanks in advance!
There was a library called inpout32.dll that allowed direct port access you can find it here
http://logix4u.net/Inpout32.dll_Discussion/write_DELPHI_for_inpout32.dll.html
But i don't know if supports windows 7.
In addition to the excellent suggestions above, check out this delphi code for writing and reading I/O. We have used the GWIOPM to do what you are asking, but note that it will be ok for 32-bit versions of Windows up to W7 etc (as is the case for most 'free' drivers). For 64-bit Windows you need a signed kernel driver. For this there are few things available at the moment. We had to write our own.
Why can't you communicate with the driver from your application? It's the best way for ring 3 application to talk with hardware in a safe manner.
However, if you really insist using drivers, you can try going to ring 0 and do direct access. It's much harder than in previous Windows versions (XP and before) but it's possible. I haven't done it myself since I don't have Windows 7, but you can try asking in asm programming forum anywhere.
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.
Has anyone successfully talked profibus from a .NET application?
If you did, what device/card did you use to accomplish this, what was the application, and did you use any kind of preexisting or available code?
We've not used Profibus, but have used DeviceNET (another CAN based protocol), Ethernet/IP and ControlNet which all have similar challenges.
We've been doing this since the late 1990's and therefore rely mainly on our own generated code using off-the-shelf hardware. The companies that have shown longevity during that period that I remember are:-
AnyBus (HMS, www.anybus.com) we've recently started using their gateway products as we can place fieldbus interfaces close to the hardware and then communicate over normal Ethernet (usually using Ethernet/IP www.odva.org). This has the advantage of separating hardware and PC using only a network cable. The Ethernet/IP .NET classes were written by ourselves as nothing much was on the market at the time. I'm sure a quick google search would find suitable class libraries
SST (www.mysst.com) have had fieldbus interfaces for more than a decade. The last SST card we used for DeviceNET still only had VB6 sample code. A good selection of fieldbus support and different form-factors e.g. PC104, PCI, PMCIA
Beckhoff/Wago (www.beckhoff.com, www.wago.com) we typically use Beckhoff for the I/O more than the interface cards but again a company that has been around a long time. They also have products that support exposing using OPC (another way for you to get I/O information without directly communicating with the hardware/devicedrivers)
I suggest not using OPC interfaces to the hardware directly (it’s OK for communication using PC (.NET)->PLC->Profibus) as you need to ensure that the control system responds to loss of control from your .NET application. I’m assuming that you are needing a profibus Master here (not a slave), so as long as your control system is intrinsically fail safe, then loss of communication should mean the control system enters an "Idle" state and therefore most of the I/O will return to the fails safe state.
We also try to ensure that we do not put safety related code in .NET. Most of our .NET code is userinterface from a PLC, but in some places we do control the fieldbus directly but ensure hardware interlocks will prevent un-safe operation, either using safety switches/relays or a small PLC with the the task of interlocking only. And above all make the system fail-safe! Loss of comms from the .NET code should shutdown the automation to the fail-safe state.
We have used Steeplechase to connect to our profibus to our automated pick system.
http://www.phoenixcontact.com/automation/32131_31909.htm
Try this: http://libnodave.sourceforge.net