I have an application in windows, that opens a com port. It attempts to call a comport, then fails and prompts me with an error.
The issue is this is very legacy software that we no longer have the source code for. I'm wondering if anyone knows of a way that can trace, or follow a program calling a com port to find out what com port its attempting to allocate.
Appearantly you can use Process Explorer (as called out in this post) to search for processes using serial ports. It sounds like you should be able to use the same searching concept called out the other post to find what you need.
I actually gave up on this solution and re-wrote the entire program in a week, it had to be done due to binary compatibility issues with the PCI cards.
I have faced with a strange behavior.
The manual claimed: "When two sockets are bound to the same port number but on different explicit interfaces, there is no conflict". Why the system fails in the following case on the step 3? Is it a bug in the OS? (my post on Microsoft forums has no answer)
Is there some workaround on this?
Step 1. process A binds the 127.0.1.1:88 (default) — OK
Step 2. process B binds the 127.0.0.1:88 (with SO_REUSEADDR) — OK
Step 3. process C binds the 127.0.0.1:88 (with SO_REUSEADDR) — fail (10013 WSAEACCES)
Note: the tcp-ports are the same, the interfaces are different and explicit (between step 1 and 2-3). User is the same.
The problem occurs in the Windows Vista (32-bit), Windows Server 2008 (32-bit), Window Server 2008 R2 (64-bit), etc.
In Windows XP it is all right: step 3 succeeds.
Update: just for reference, the same problem: Windows 7 socket bind behavior difference from XP, with reuse address socket option (WSAEACCES 10013 error)
Binding two sockets to the same explicit interface and port when both sockets use SO_REUSEADDR is guaranteed to succeed, even the Microsoft documentation says so. It has to be a bug in your code, either you are not enabling SO_REUSEADDR on both sockets prior to calling bind(), or you are not actually binding both sockets to the same explicit interface and port.
bind() does not return WSAEACCES if the interface/port are already in use. It returns WSAEADDRINUSE instead. WSAEACCES means you tried to bind to something that you do not have permission to bind to. That is a different kind of error condition.
In the second example (in the section examples) on this link, there is a description on using WM_QUERYENDSESSION to abort a shutdown. It also states that this does not work on versions of windows later than XP. This is conflicting with the advice given on another question here at stackoverflow. What is the correct answer? I do not have a computer with either so I am unable to test.
Some applications got the WM_QUERYENDSESSION handling wrong (Not passing to DefWindowProc, they incorrectly returned 0 even though they did not intend to block shutdown) and so MS changed it with Vista, you now need to call ShutdownBlockReasonCreate()
#Konamiman: shutdown.exe -a will abort a "scheduled" shutdown yes, but not a "normal" shutdown by someone calling ExitWindowsEx()
If anything else fails, remember that from command line it is shutdown.exe -a; maybe you could invoke this using the Process class.
EDIT. When mentioning the Process class I happily assumed that the question was about .NET programming, now I see that .NET is not mentioned neither in the question nor in the tags. Anyway I believe that there are ways to run executables from other programming environments as well.
Is there any library or software or any way of saving the state of a single process in Windows to a file, then restoring the running process to a running state with all the memory already loaded at a later time?
I am aware that open handles will have to be re-opened, threads may have to started, etc, but can the heap and a single thread stack at least be restored?
I saw this question, but the answers are all for linux and most of them say it can't be done.
I know I can make all of my data structures serializable and do it myself, but I'd like to know if it is possible without that.
Raymond Chen (who may even kick Jon Skeet's ass when it comes to obscure Windows knowledge) says it isn't possible.
Essentially, unless your process uses absolutely no system resources (e.g. handles of any kind), there's always going to be some OS state which you can't save and restore.
The most practical way of solving this problem is to create a VM running another instance of Windows and run your process inside that:
You can make the guest OS as lightweight as possible by using nLite.
You can then use the VMWare VIX API to suspend/resume the VM programmatically.
This of course suspends the guest OS, and your process with it, solving the OS state problem.
>> •You can make the guest OS as lightweight as possible by using nLite.
To add to the above statement - The official lightweight version of Windows XP is "XP Embedded" or "Windows Embedded Standard". It is a heavily componentized version of XP that lets you slim down the XP image as small as 40 MB.
The "light weight" version of Windows 7 is Windows Embedded Standard 2011 , which is currently in Beta and available for download (connect.microsoft.com/windowsembedded)
Of course , it is not a freeware unlike NLite.
Thanks,
Srikanth
Just curious here: is it possible to invoke a Windows Blue Screen of Death using .net managed code under Windows XP/Vista? And if it is possible, what could the example code be?
Just for the record, this is not for any malicious purpose, I am just wondering what kind of code it would take to actually kill the operating system as specified.
The keyboard thing is probably a good option, but if you need to do it by code, continue reading...
You don't really need anything to barf, per se, all you need to do is find the KeBugCheck(Ex) function and invoke that.
http://msdn.microsoft.com/en-us/library/ms801640.aspx
http://msdn.microsoft.com/en-us/library/ms801645.aspx
For manually initiated crashes, you want to used 0xE2 (MANUALLY_INITIATED_CRASH) or 0xDEADDEAD (MANUALLY_INITIATED_CRASH1) as the bug check code. They are reserved explicitly for that use.
However, finding the function may prove to be a bit tricky. The Windows DDK may help (check Ntddk.h) - I don't have it available at the moment, and I can't seem to find decisive info right now - I think it's in ntoskrnl.exe or ntkrnlpa.exe, but I'm not sure, and don't currently have the tools to verify it.
You might find it easier to just write a simple C++ app or something that calls the function, and then just running that.
Mind you, I'm assuming that Windows doesn't block you from accessing the function from user-space (.NET might have some special provisions). I have not tested it myself.
I do not know if it really works and I am sure you need Admin rights, but you could set the CrashOnCtrlScroll Registry Key and then use a SendKeys to send CTRL+Scroll Lock+Scroll Lock.
But I believe that this HAS to come from the Keyboard Driver, so I guess a simple SendKeys is not good enough and you would either need to somehow hook into the Keyboard Driver (sounds really messy) or check of that CrashDump has an API that can be called with P/Invoke.
http://support.microsoft.com/kb/244139
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Restart
I would have to say no. You'd have to p/invoke and interact with a driver or other code that lives in kernel space. .NET code lives far removed from this area, although there has been some talk about managed drivers in future versions of Windows. Just wait a few more years and you can crash away just like our unmanaged friends.
As far as I know a real BSOD requires failure in kernel mode code. Vista still has BSOD's but they're less frequent because the new driver model has less drivers in kernel mode. Any user-mode failures will just result in your application being killed.
You can't run managed code in kernel mode. So if you want to BSOD you need to use PInvoke. But even this is quite difficult. You need to do some really fancy PInvokes to get something in kernel mode to barf.
But among the thousands of SO users there is probably someone who has done this :-)
You could use OSR Online's tool that triggers a kernel crash. I've never tried it myself but I imagine you could just run it via the standard .net Process class:
http://www.osronline.com/article.cfm?article=153
I once managed to generate a BSOD on Windows XP using System.Net.Sockets in .NET 1.1 irresponsibly. I could repeat it fairly regularly, but unfortunately that was a couple of years ago and I don't remember exactly how I triggered it, or have the source code around anymore.
Try live videoinput using directshow in directx8 or directx9, most of the calls go to kernel mode video drivers. I succeded in lots of blue screens when running a callback procedure from live videocaptureing source, particulary if your callback takes a long time, can halt the entire Kernel driver.
It's possible for managed code to cause a bugcheck when it has access to faulty kernel drivers. However, it would be the kernel driver that directly causes the BSOD (for example, uffe's DirectShow BSODs, Terence Lewis's socket BSODs, or BSODs seen when using BitTorrent with certain network adapters).
Direct user-mode access to privileged low-level resources may cause a bugcheck (for example, scribbling on Device\PhysicalMemory, if it doesn't corrupt your hard disk first; Vista doesn't allow user-mode access to physical memory).
If you just want a dump file, Mendelt's suggestion of using WinDbg is a much better idea than exploiting a bug in a kernel driver. Unfortunately, the .dump command is not supported for local kernel debugging, so you would need a second PC connected over serial or 1394, or a VM connected over a virtual serial port. LiveKd may be a single-PC option, if you don't need the state of the memory dump to be completely self-consistent.
This one doesn't need any kernel-mode drivers, just a SeDebugPrivilege. You can set your process critical by NtSetInformationProcess, or RtlSetProcessIsCritical and just kill your process. You will see same bugcheck code as you kill csrss.exe, because you set same "critical" flag on your process.
Unfortunately, I know how to do this as a .NET service on our server was causing a blue screen. (Note: Windows Server 2008 R2, not XP/Vista).
I could hardly believe a .NET program was the culprit, but it was. Furthermore, I've just replicated the BSOD in a virtual machine.
The offending code, causes a 0x00000f4:
string name = string.Empty; // This is the cause of the problem, should check for IsNullOrWhiteSpace
foreach (Process process in Process.GetProcesses().Where(p => p.ProcessName.StartsWith(name, StringComparison.OrdinalIgnoreCase)))
{
Check.Logging.Write("FindAndKillProcess THIS SHOULD BLUE SCREEN " + process.ProcessName);
process.Kill();
r = true;
}
If anyone's wondering why I'd want to replicate the blue screen, it's nothing malicious. I've modified our logging class to take an argument telling it to write direct to disk as the actions prior to the BSOD weren't appearing in the log despite .Flush() being called. I replicated the server crash to test the logging change. The VM duly crashed but the logging worked.
EDIT: Killing csrss.exe appears to be what causes the blue screen. As per comments, this is likely happening in kernel code.
I found that if you run taskkill /F /IM svchost.exe as an Administrator, it tries to kill just about every service host at once.