I've written an Windows Server which uses the WMI feature of Windows to monitor system health. For that purpose, a WMI connection is opened, queried and closed every thirty seconds. That works quite well on Windows Server 2008 (R2).
On the other side, I have a couple of Servers running Windows Server 2003 x64, which run constantly into BSODs when using my Service (and only when using my Service). The Error code is commonly 0x9c, sometimes 0x19. Others told me that system memory may be corrupted, but it's very unlikely since all 2003-x64-based servers are experiencing that problems.
The Windows error log lists three error messages of type "WDMxWMI", without any further details, before the system reboots because of an bluescreen.
I don't know why this happens, and I neither know if, or how my program could be the reason for that, since I'm using the WMI exacly like the MSDN examples told me. Last but not least, it works absolutely fine on 2008-based servers.
I'll be thankful for any advice.
A bugcheck of this nature seems to indicate a serious hardware problem.
http://support.microsoft.com/?kbid=329284
https://serverfault.com/questions/7060/troubleshooting-the-dreaded-0x9c-bsod
Related
There is a multithreaded program that operates simultaneously with a device via COM port based communication and remote (IP) video stream. The program also uses OpenCV library to process the data.
The trouble is that it shuts down without any signals (neither run-time, nor any other errors are caught; log file has no anything useful as well). The most top level application error event handler is set and still there are no any signs of the program crash. It just closes after awhile.
The biggest difficulty is that it works fine on all our PCs for days non-stop. But fails on customers PCs so that testing process is very slow. Customer is in a different country (Asian localization, whilst ours is European), but the program is built with Unicode support.
So far we have got some assumptions about localization issues and antivirus activity... but it gives nothing in result.
The program is written with MinGW 4.4.x C++ and wxWidgets 2.9.3
Any suggestions of the probable origin would be appreciate.
Solved.
The problem was inside OpenCV build 2.3.1, that we use. The function cv::imdecode(...) uses stdio.h`s tempnam() function to generate temporary file during decoding. Under x86 Windows systems this function fails after 32767 new names for temporary file. Under x64 Windows systems it returns some nonsense string, but it still works.
So the solution I came with was to change the way of receiving-decoding images from our device.
Thanks everybody for comments.
I have a strange problem - after my C++ application runs for 39 hours on Windows XP, the network is broken and the application fails. Seen that several times. When I try to "ping localhost", the prompt says "no resources". I found this thread in Internet, where people advice to make "ipconfig /renew".
The thing is I just want to know, what actions (Windows API calls) causes that. I'm nearly 100% sure that the problem is in the network card (because the other card works well), but I just want to understand, what my actions cause that.
Unforunately, my application consists of megabytes of code, so I can't just uncomment a few lines to see if I can reproduce error now.
Is there any list of Windows API calls that are executed by network card driver? For instance, "sendto" is most likely executed by driver, because it sends data to network.
Is there any test (like Acid test for browsers), which can show if network driver does not behave correctly?
It kind of sounds like you've run out of sockets. Are you sure you're freeing the sockets once you've used them?
Make sure that your network card is updated with latest driver or re install the driver and then restart the machine once.
i need to find away to turn on the pc from c++ application ,
is there any way to do this?
Thanks
If the computer is off, it can't be executing code, and therefore can't turn itself on programmatically.
ACPI changes that somewhat, but for us to be able to help, you have to be more specific about your exact requirements.
If you need to turn on a different computer, take a look at Wake-on-LAN.
You will not be able to write a program to turn a computer on that the program itself is installed on.
If you need to write an application that will turn on a different computer, Wake-on-LAN is the tool for you. Modern desktops have NICs that is always receiving power - even if the computer is in an S5 state. Assuming the BIOS supports it and it is enabled.
Wake-On-LAN works by sending a Magic Packet to the NIC. The details of what the payload consists of is outlined in the article.
This is possibly a duplicate of C#: How to wake up system which has been shutdown? (although that is C#).
One way to do it under windows is to create a timer with CreateWaitableTimer(), set the time with SetWaitableTimer() and then do a WaitForSingleObject(). Your code will pause, and you can put the computer into standby (maybe also hibernation, but not shutdown). When the timer is reached, the PC will resume and so will your program.
See here for a complete example in C. The example shows how to calculate the time difference for the timer, and how to do the waiting in a thread (if you are writing a graphical application).
I have to add, you can also schedule the computer to wake up using the Windows Task Scheduler ('Wake the computer to run this task'). This possibly also works when the computer is shut down. There is also an option in some computers BIOS to set a wake time.
Under Linux, you can set the computer to wake up by writing to a special file:
echo 2006-02-09 23:05:00 > /proc/acpi/alarm
Note that I haven't tested all of this, and it is highly dependent on the hardware (mainboard), but some kind of wake-up should be available on all modern PCs.
See also: http://en.wikipedia.org/wiki/Real-time_clock_alarm ,
and here is a program that claims to do it on windows: http://www.dennisbabkin.com/wosb/
Use strip. If you require a Windows computer to be turned on, the cross-tools i686-w64-mingw32-strip or x86_64-w64-mingw32-strip should be used. These command-line programs modify an executable, and the result is able to turn on a computer.
How could you turn on a computer from an application, when no processes are running on it when it's shut down ? You can turn on another computer (Wake on Lan), but not the one you are running.
It is possible.
First thing to do is configure Wake On Lan. Check out this post on Lifehacker on how to do it: http://lifehacker.com/348197/access-your-computer-anytime-and-save-energy-with-wake+on+lan.
(Or this link: http://hblg.info/2011/08/21/Wake-on-LAN-and-remote-login.html)
Then you need to send a magic packet from your C++ application. There are several web services that already do this from javascript (wakeonlan.me) , but it can be done from within a C++ application as well.
Chances are, that if you want to do this, you are working with servers.
In such case, your mainboard may should an IMPI baseboard management controller.
IPMI may be used to cycle the chassis power remotely.
Generally, the BMC will have its own IP address, to which you may connect to send control messages.
I maintain an application that uses the win32 EnumPorts() function to help determine the set of serial ports installed on the computer. I have seen cases on some computers where the call to get this information fails with a GetLastError() code of 1722 (RPC server is unavailable). I assume that this has something to do with either registry settings or a required service being disabled but my search so far has been rather fruitless. Has anyonw else encountered this issue?
In answer to Euro Micelli's comments. I am specifically attempting to fill a pick list that will allow the user to choose an available picklist. To begin with, I relied exclusively on EnumPorts() to provide me a list of potential serial port names. It has proven to be unreliable, however in several senses: It has not always provided the complete set of port names and, as I have recently seen, it can fail to function altogether when the "RPC service is unavailable". Why RPC is needed to find out what ports are available on the local machine is completely beyond me but there it is. This latter problem was the final straw. So far as relying completely on the list of names provided, i filter these names using the GetDefaultCommConfig() function to determine the exact nature of each of the names that I came up with.
In my experience, the list of names provided by the previously mentioned registry key has been the most reliable method for getting port names. As a matter of fact, I can see the key get updated as I disable port drivers in the device device manager. Under normal experiences, I would agree with the assessment that relying upon a particular key is fraught with peril. In this case, however, M$ has never provided a decent mechanism to evaluate the names of available ports.
I should point out that I have already replaced the call to EnumPorts() with an algorithm that scans the registry key: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM for serial port names. This should resolve the issue once my software is released. What I am after is pointers that can be given to customers who are using the released package at the present.
I'm not an expert on EnumPorts, but I strongly advice against relying on registry keys.
Key definitions might change in the future.
Key definitions might not be what you think.
There might be ways to "be a serial port" which don't include those keys.
The keys might not reflect up-to-date status, etc. etc.
You should always rely on the APIs available.
If an API doesn't behave for you, let's try to figure out why. Maybe with a little extra information we can help better:
What is it exactly that you need to do with the serial port?
There are a lot of weird serial ports these days: USB serial cables, Bluetooth, cell phone modems with GPS,... It might be something plugged into the computer and long forgotten since.
To find out which port is causing the problem you could try going into device manager, select "Show hidden devices" in the "View" tab and deleting them until the problem goes away. That might allow you to zero in on the problem.
I know it's not a direct answer to your question, but have you considered using a different method for enumerating the serial ports? In my applications I use the Setup API, using code from P J Naughter's website: http://www.naughter.com/enumser.html, and I find it works well.
I know this question is extremely old, but I stumbled onto it today, and noticed no-one gave an explanation.
The reason for RPC is because you're calling a spooler function - you are asking the print spooler to return a list of printer ports, which happens to include the COM ports in most cases. I believe this may explain your slightly unreliable results.
RPC is used to pass the request from your process to the active spooler process, and the RPC Server is unavailable message occurs when the spooler service is not running (or not responding properly).
I have emailed Entrek and they seem to be asleep.
Does anyone else here use Entrek CodeSnitch? If so, have you found a way to use it with Windows Mobile 5, 6, or 6.1 ?
I really need to verify my application doesn't have any memory leaks, etc. And CodeSnitch does a great job of it. But only with Windows Mobile 2003. :/
Thanks.
What's not working? Is it a client connectivity issue?
The older version used PlatMan for a communications layer, which is problematic from a Visual Studio standpoint (which ships with CoreCon), but if you have any tool installed that has Platman (eVC, Platform Builder) then that should still work fine since WinMo 5.x and 6.x are still based on CE 5.0.
I do know that Entrek has a newer version in beta (I have it) so you might try pinging them again. They tend to be pretty busy, but I've always gotten responses (though I know them well and personally, so that might not be any indicator for you).
I also see that they have their phone number posted on their web page. I'd give them a call. I do recall them saying the new version is supposed to address WinMo issues (I rarely use WinMo proper) so it's definitely worth a try.
I've not used CodeSnitch. But I have had success using the Application Verifier Tool to identify my leaks in WM5 and 6.
Getting it up and running can be a bit of a pain. But I find it to be a good tool and the price is right.
Here's a tutorial to get you started.
I've used CodeSnitch on windows mobile 5, 6 and 6.1 devices with no problems.
Make sure you have the v1.4 installed and applied the v1.4 patch which is referenced here.
Like ctackle says, you need an older communications layer called CoreCon. I've also found CETK has CoreCon in it as well and it's not as big as eVC or Platform builder.
You need to setup the device connection settings to use ActiveSync (both transport and startup server), it does not seem to matter what the connection is called so something like Pocket PC will work fine.
The other gotcha I found is that you need to edit the codesnitch and procman shortcuts and add "/targetcpu:armv4i" to the command line arguments for them to work on WM devices.
I have also found them recently to be non-responsive to support emails as well :(