When a volume is attached to file system, on Windows,
the Window explorer detects the volume and refreshes automatically.
I wonder the technique.
How do an program(include device driver) get the notification?
-Of course, it doesn’t mean a polling. I want to get an event(or a message).
I would like to get the notification when a network volume(like SMB) is attached.
Thanks in advance.
You're going to have to do some research, but basically you just need to register with the Windows IO Manager so that when the device is connected, some part of your code is called. RegisterDeviceNotification() is probably a good place to get started. When the device is connected, the IO Manager will send you a message, so you should make sure you have a proper callback setup for the message.
It would not hurt to read up on Windows Devices Services from the Windows System API. Depending on what you are doing, you may or may not need a driver as the generic driver provided by Microsoft is often good enough. For drivers, check out the Windows Driver Kit, it contains an excellent collection of sample drivers, as well as Win32 code for interfacing with drivers and working with hardware.
Good luck!
Related
I'm rather unexperienced on the field of microcontrollers, I come from a Java background so the question might seem a bit noob but I didn't find much information on this.
So is it possible to debug an STM32F4 board via bluetooth (using eclipse or some othe IDE)? And if so could you send me some links that might help? We're building a robotic car controlled by a discovery board and debugging using an USB cable is not really an option if we don't want to disassemble the whole stuff every time something goes wrong. Hence this would really come in handy. So any help is appreciated
For doing this you would need to find a "Bluetooth Enabled" Debugger. I have never seen any and not sure whether there exists such thing or not.
I would suggest you one thing:
Assuming you have bluetooth connectivity between your board and your Machine,
Insert Debug strings: Send some strings from your board to your PC via Bluetooth. These strings will give you what's going on in Circuit.
For example, After Initialization, send "Init Completed" and like that. You can see these strings and see what's wrong.
I usually do this for my Wireless Device.
What you're wanting to do is really not practical; you're coming at this from way too high a level and trying to imagine the system as if it were running an operating system from the word go.
When you get the STM32 it as empty shell; you need to program it to do what you need to do and the only [sensible] way to get register-level debugging is to use a JTAG interface.
If, and this is a big if, you get it working reliably, but just want to give some debug information back while it is running, you could write a load of routines within the code to send out debugging messages when it enters certain parts of the program - and send it out over Bluetooth - but this is nothing like what you're used to single stepping through your Java code with Eclipse. If you want to do that kind of thing, you are going to have to put a little connector on that allows you to connect your JTAG or two-wire debugger cable to the processor. Even then, when you do that, you will be completely resetting your program and not simply single stepping through from where it went wrong.
You could insert a monitor program within your program to send out register values, program status etc over Bluetooth, but you still have to write the inital code and the only way to do this with out a ridiculous amount of trail and error is via your JTAG or two-wire interface.
Would this product work? It's a "IOGEAR Bluetooth Serial Adapter, GBC232A" for connecting to a serial port over bluetooth. I'm interested in wireless debugging too because my surface-clone dev computer only has one usb and this seems like it could be convenient over a tangle of usb cords and a usb hub. I have zero experience with any of this, so maybe you could validate or invalidate it as an option. I figure it just needs a proper serial connector wired up on the board and power from on-board?
I made a device driver. But my system crashed at the moment when it was deleting the device object. I think the symbolic link was deleted and it crashed after it was trying to delete the device as I can't see the symbolic link in the Global.
How do I delete this device now. It also gives me a error popup(system cannot find the file specified Device\Mydriver) when I try to open the listed Mydriver under devices from Winobj.
I tried starting the driver's service again. I do get a handle back when opening the service. But it wont start now. giving the error value of Cannot find the file specified. I was working fine, i mean starting the driver before this crash.
I am a beginner with drivers and doing this to learn, please guide.
I have taken this from : Programming microsoft windows driver 2nd edition by woney
I hope this helps.
Removability of devices in a Plug and Play environment is the ultimate source of the early-unload problem
mentioned in the text. it’s your responsibility to avoid sending an IRP to a driver that might no longer be in memory
and to prevent the PnP manager from unloading a driver that’s still processing an IRP you’ve sent to that driver.
One aspect of how you fulfill that responsibility is shown in the text: take an extra reference to the file object
returned by IoGetDeviceObjectPointer around the call to IoCallDriver. In most drivers, you’ll probably need the
extra reference only when you’re sending an asynchronous IRP. In that case, the code that ordinarily
dereferences the file object is likely to be in some other part of your driver that runs asynchronously with the
call to IoCallDriver—say, in the completion routine you’re obliged to install for an asynchronous IRP. If you send
a synchronous IRP, you’re much more likely to code your driver in such a way that you don’t dereference the file
object until the IRP completes.
Use the interactive boot option and don't load the troublesome driver. Then you can experiment perhaps by adding diagnostic instrumentation to the driver or other debugging techniques to determine the underlying problem.
For the needs of my software I need to create a printer driver which will allow me to save all the images which are sent to it to files and then open my program's window letting the user to do something with the rendered pages.
I have found this article, but the sample uses the FILE: port, while I need to make my own port, dump the images to files and run an executable. However, I think I can accomplish my task by doing that in the driver's code, but I am not really sure that it is a good decision, since it is a driver, even though it is a user-mode driver.
I would be glad to hear any advice on my problem. Thanks in advance.
You need a port monitor, not a driver. See my answer to this question. You can use RedMon, but I recommend using the sample port monitor found in the WDK instead.
If you are OK with using XPS as format you can use the Github project: Microsoft/Windows-driver-samples/print/XPSDrvSmpl
https://github.com/Microsoft/Windows-driver-samples/tree/master/print/XPSDrvSmpl
Installer: http://wixtoolset.org/
Application: Listen to internal port
Flow: Install printer and application from a single installer. User prints something with your driver and while the application listens to the internal port. When data is sent the application picks it up. This is for XPS, can be converted to PDF, but the flow is similar no matter what you are printing. If you need anything else check out Microsoft/Windows-driver-samples/print/ on GitHub or other sources specific to your needs.
I need to capture the DeviceIoControl() system calls of an application. On linux, strace can be used to analyze all ioctl calls. Is there any similar functionality on windows?
MSDN website recommends a program called "Process Monitor" to analyze the real-time activities of executables. However, "Process Monitor" does not show anything about DeviceIoControl calls.
Have you tried OSR's IRPTracker?
IrpTracker allows you to monitor all I/O request packets (IRPs) on a system without the use of any filter drivers and with no references to any device objects, leaving the PnP system entirely undisturbed. In addition to being able to see the path the IRP takes down the driver stack and its ultimate completion status, a detailed view is available that allows you to see the entire contents of static portion of the IRP and an interpreted view of the current and previous stack locations.
To capture the DeviceIoControl() function you can use an API hook. My company provides Deviare, a hook engine with a high level interface. You don't need to know a lot about hooking it can be used freely (just display a dialog saying unregistered version). It includes a hook console with source code.
Recently discovered Rohitab's API Monitor
It hasn't been updated for 2 years, but it does work on my Win7 x64. It has very good API filtering capabilities.
The Dr. Memory (http://drmemory.org) tool comes with a system call tracing tool called drstrace that lists all system calls made by a target application, including NtDeviceIoControlFile, along with their arguments: http://drmemory.org/strace_for_windows.html
I am trying to make U9 telit modem send SMS messages. I think I handle protocol correctly, at least, I manage to send them, but only under these circumstances: the native application was executed beforehand, and killed by task manager (without giving it a chance to initialize things).
It looks like the supplied application is good at doing certain initialization/deinitialization which is critical. I also see the difference between the two states in output of AT+CIND command. When I am trying to do things on my own, it returns zeroes (including signal quality), but when I run the same command after killing the native application, the output looks reasonable.
I am out nearly of ideas. I have tried many things, including attempts to spy at modem's COM ports (didn't work). Haven't tried setting windows hooks to see what the application is trying to get thru.
Perhaps you have encountered a similar situation?
Agg's "Advanced Serial Port Monitor" actually helped a lot. Sometimes it caused blue screen, but it helped uncover secret commands which seem to help. AT+PCFULL is not described anywhere on the net, for example. The real trigger of non-operatio was AT+CFUN, the power disable/standby feature.
Also, it appeared that we have more issues. At first, the modem appears on the bus only as disk drive. It doesn't want to appear as any other devices before the drivers are installed. So, the U9 Telit software sends an IOCTL to disk driver to tell the modem to reappear as more devices (modem, 3 serial ports, another disk drive).