|
Hi,
Find the line :
$(REBASE) -b 0x00400000 -x $(TARGETDIR) -a $(TARGETDIR)\$(TARGET)
and add ".sys" at the end. So we have :
$(REBASE) -b 0x00400000 -x $(TARGETDIR) -a $(TARGETDIR)\$(TARGET).sys
and everything is alright 
Cheers,
Phil.
|
|
|
|
|
Hi,sir
So excited to talk to you.
Can I ask you some questions?
Since I want to replace the rdpdd.dll which worked well in windows terminal service, could you tell me how can I do and what will I?
I know the display device of one window is determined by the "default Desktop" of the windowstation. Can I change the Desktop's display device?
Or how Can I create a Desktop with special display device just like rdpdd.dll?
Best regards
fang
|
|
|
|
|
Hi,
I met another problem:it cant work after installed.
Debugger shows (in appmonitor) hFile==NULL:
hFile = CreateFile("c:\\video.dat", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
Could you tell me how to let it work?
Best regards
fang
|
|
|
|
|
The display driver must be installed and enabled before you can run the monitor application.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thank you very much.
I have had it work well.
|
|
|
|
|
A session can have multiple desktops associated with it however only one can be active at any one time. Generally, all desktops will be sharing the same display driver there is no reason to associate different display drivers with different desktops. However, a display driver for a session can be changed provided it is a local session. I.E. you can go into display properties and change the display driver. Remote is a different type of session and is initialized differently or when using FUS is switched into this mode.
In that instance there really is nothing "special" about RDPDD.DLL on the outside as it is just a registered display driver for a particular type of session. You can write any display driver you want and install it to replace the console display driver if you want. The difference in TS is that the graphics are remoted instead of display locally. The driver development article 6 shows how to create your own display driver and use it locally as a multiple monitor setup.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thank you for your response.
In fact, the work I want to do is to implement a virtual display driver just like RDPDD.DLL except for a different protocol(not TCP/IP, not RDP). So I am confused about how to do.
Is it evitable for me to create a remote session with a deamon service just like MS Terminal Service?
Best regards.
fang
|
|
|
|
|
You can do this two ways.
1. Hijack the existing session like VNC or GoToMyPc or PCAnywhere would do.
2. Implement an add on to Terminal Services with your own protocol.
#1 This is really a shadower of the existing session and as noted has been done over and over and you should be able to find things on the net.
#2 This would require you talk to Microsoft. Only one company currently has an alternative to RDP.
I would not be able to provide any further information on TS specifics that would not be found on MSDN.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thank you for your advises.
From my view, VNC is usually used to monitor the console session, so, I think it cannot satisfy what I should do.
Could you please tell me what is a shadower and give me some links to them ?
Best regards.
fang
|
|
|
|
|
nkpunk wrote: From my view, VNC is usually used to monitor the console session, so, I think it cannot satisfy what I should do.
That is exactly what a shadower is. It mirrors an existing display to another location, so both locations see the same thing. You could eliminate the console view by disabling the monitor or something so it only goes to one place however you still would be doing essentially the same thing as VNC. Doesn't matter if you do it on the console or the rdp session, it's the same thing you would be required to have an RDP connection or a console logon. You can then scrape the screen or whatever you want to do. However, again if you want to do this independent of those scenarios you would need to follow route #2.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thank you very much.
I just have tried to replace the console's display with a virtual display driver, and I succeeded.
How can I replace the RDP display device?
It seems there is no way to achive this in "Control Panel".
Best regards.
fang
|
|
|
|
|
Hello sir,
I'm getting ERROR_NO_MORE_USER_HANDLES eror cocde if my application ruins for long time. so I guess that it should be problem of unclosed handles andI found you article on the same.
I just read your article to find out the "Handle leak", I find it very usefull ,I tried the example you have explained using "Notepad" but I faced some problems while debugging.
I'm using Windbg 6.9.
can you please tell me how to do "Kernal Debugging" , I had select "Kernel Debug" from File menu , click on "Local" tab and "Ok", thn a command prompt comes as "lkd>" .
Does this process is right ?
Then I started "Notepad" and open a file "c:\Example.txt" .
I entered folowing sequence of command and get their output
lkd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
....
....
PROCESS 88f2f270 SessionId: 0 Cid: 07d4 Peb: 7ffde000 ParentCid: 0724
DirBase: 0a480800 ObjectTable: e9c557c8 HandleCount: 89.
Image: notepad.exe
lkd> !handle 120 ff 88f2f270
processor number 0, process 88f2f270
PROCESS 88f2f270 SessionId: 0 Cid: 07d4 Peb: 7ffde000 ParentCid: 0724
DirBase: 0a480800 ObjectTable: e9c557c8 HandleCount: 89.
Image: notepad.exe
Kernel Handle table at e2e19000 with 1363 Entries in use
0120: Object: 89020010 GrantedAccess: 0012019f Entry: e1004240
Object: 89020010 Type: (0a130000)
ObjectHeader: 8901fff8 (old version)
HandleCount: 0 PointerCount: 2298609652
Directory Object: 00000000 Name: (*** Name not accessible ***)
My question why its not showing me the name of file whivh is opened in notepad like example you have given in your article?, also the HandleCount and PointerCount vaues are very different.
Secondly,
When I atached Windbg to "Notepad" , open "c:\Example.txt" file and run following commands
0:001> !handle 0 0
46 Handles
Type Count
Event 5
Section 6
File 4
Port 1
Directory 3
Mutant 11
WindowStation 2
Semaphore 5
Key 7
Desktop 1
KeyedEvent 1
0:001> !handle 0 ff Key
....
....
Handle 2c
Type Key
Attributes 0
GrantedAccess 0xf003f:
Delete,ReadControl,WriteDac,WriteOwner
QueryValue,SetValue,CreateSubKey,EnumSubKey,Notify,CreateLink
HandleCount 2
PointerCount 3
Name \REGISTRY\MACHINE
Object Specific Information
Key last write time: 12:48:26. 7/9/2008
Key name MACHINE
.......
.......
7 handles of type Key
0:001> !handle 0 ff File
.........
.........
Handle 10
Type File
Attributes 0
GrantedAccess 0x100020:
Synch
Execute/Traverse
HandleCount 2
PointerCount 3
No Object Specific Information available
.........
.........
4 handles of type File
Why the Windbg shows the exact value of regisrty key opened  ( like your example in article) but does not give any information regarding the file name for respective handle  ?
Can you please tell me whethere I'm missing sometihng as i have to remove a lot of handle leaks.
Thanking you
Digambar Borse
|
|
|
|
|
Hi Toby. I just checked your webpage - you have certainly led the developer life I'd wished for! Anyway, I just wanted to ask you a very quick question before I try to absorb your very cool debugging tutorials.
I have an application I have to maintain that is causing Windows to lock completely - ie. the mouse pointer can no longer be moved.. nothing else can be done except powering off the machine. Two questions really:
1) Can mutex/event/semaphore code cause this? (I'm think "yes" because I have the feeling I fixed a problem like this once before related to deadlocking with MFC CSingleLock objects)
2) Will reading your debugging tutorial #7 (and its prerequisits) put me in a position where I can identify this problem?
BTW, I have never really written an x86 assembler code before (done heaps of 680x0 code though).
Thanks
Paul
|
|
|
|
|
Yes, locks can cause this problem but not all locks it would have to be a specific lock that would block some aspect of these code paths. That would mean somehow blocking the thread which handles input or blocking the drawing operations of GDI, which both are possible. So if GDI is locked or the display driver is locked then you would never be able to draw or see any user feedback. This is more common then blocking the input thread.
Other possible causes could be using up all the GDI objects, corruption in the display driver. You could even have a thread which sets itself to very high priority and then starves the rest of the system. This commonly happens with audio applications.
The debug tutorial #7 should help you with the locks. I would setup a kernel debugger and first try !running -t to see what all the CPUs are doing. See if they are running in a thread or if they are idle. You can also do !ready to see if any threads are waiting to run, perhaps there are a few threads waiting to run but they are lower priority. !thread -1 ff should show you the current thread of the processor you broke into and the priority will be listed. !locks -v should help you search for locks which may be blocking the system.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thanks Toby. I have all your tutorials printed out so I guess I'll start at the beginning - ie. forget about my problem application and upskill myself with debugging at this level.
Much appreciated - if I make progress on this one, I'll update you as if may help you and others with similar problems to me.
Cheers
Paul
|
|
|
|
|
Hi,Sir
Thank you for your greate job.
I want to write a driver to support multiple virtual video miniport devices.
Could you give me some advices? Actually, I am very confused to do this.
Best Regards
f ang
|
|
|
|
|
Hi. Were you debugging on win9x, i can't see even one debugger wchich will allow to do this effectively, like check on what thread is waiting, any debuger displaying handles, tried to use procexplorer to show handles with waitforsingleobiect,, not mentioning symbols for win98 avability
|
|
|
|
|
Windows 9x isn't the best platform to be debugging. The last time I checked a few years back, the WINDBG from MSDN actually worked you just had to copy it over (the install wouldn't work directly on the machine). It wasn't perfect, but you could at least set some break points and do some stepping of code. Some of it was slow though and you couldn't force a break in. The debug APIs are mostly the same so that's how the debugger can still at least do some control, but some extensions most likley won't work if they are looking for specific NT memory locations.
You can also try SoftICE for 9x, used to work pretty good as well as there is a debugger you can download from Microsoft for Windows 9x/ME but it does require a seperate machine as it is a kernel debugger. You may also want to try to find turbo debugger for windows or another free debugger somewhere, maybe ollydebug would work? Try http://programmerstools.org/[^] but I've been luckly and in recent years it's been rare that I have had to debug Windows 9x and the last time I even did was a few years back. All this stuff is on NT. I'm so spoiled now adays I shutter at just debugging a 2000 machine and that's still light years ahead of Windows 9x debugging!
Microsoft Vistual Studio 6.0 also had a debugger you could use in Windows 9x and seemed to work well, but it is kind of a heavy weight application to be installing on a test machien to debug, but it should also work for you.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
I would be interested in knowing what Compiler the author recommends be used to develop the examples in these articles.
The articles are in C and yet it appears that the current versions of MS Visual C++ cannot compile C language files anymore.
|
|
|
|
|
The new MS Visual C/C++ compilers should still be used to compile the only good high level language, C
The articles did use Visual Studio C/C++ 6.0 compiler however a few of the articles have recently been ported to using Visual Studio 2005/.NET. The only problems that people encountered were new command options that needed to be used and old command line options that needed to be removed. Also, for driver development depending on the environment you setup the compiler may add libraries which would make the executable not loadable in the kernel. Using the DDK environmnet instead should avoid this issue.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
I am a firmware guy who mostly uses the Windows desktop as a development cross compilation platform.
Thus, I have yet to figure out how to force the current versions of Microsoft Visual C++ to compile straight C.
Could you describe step by step how your examples could be compiled using the current Microsoft compilers or point to an article here which has already addressed this issue.Thanks.
|
|
|
|
|
|
So the C compilation capability is still there in the current MS Visual C++, but not fleshed out in the GUI.
One has to write one's own Nmake to activate the C compiler.
Does this means that for C compilation, the developer simply does not use the current MSVC++ GUI at all, and hand-types everything into his own array of makefiles and batch files ?
|
|
|
|
|
The GUI should still work, just create your files as ".C" and probably just have to select "C++ Project". So while the option to create a "C" project is not there, it's likely just implied with "C++" provided you name the files appropriately. THe only problem would be if they default some of the command line options inapproprately for C++, which would then just need to be changed.
I do not use the GUI and have not for a long time though. I like to use makefiles and build environments and work from the command line. It is much easier for me this way to build large projects and independent projects together (I just do nmake from top directory). The build environment I had was very simple I am actually thinking of switching to the latest DDK build environment, would be easier for other people to setup as well then.
Mostly I just use makefile, very little batch files unless really nesecary. So just do "nmake" and build the project. Any batch files would likely just be called from the makefiles anyway and not exposed to the developer. The batch files would also be dependent on the build environment, for example sometimes people use "perl" or "VB Script" to get called from their build environment or other exe files to do special things like build installation and setup programs, call install shield, or whatever they need to do.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Thanks. I printed out and am about to read 5 of your device driver articles which appear very instructive so I just wanted to have that item ironed out beforehand.
This issue of Choice Of Compiler for various development intents and purposes would be a great article for some of the industrious people here to write.
Microsoft, Intel, Borland, Watcom etc.
However, I think you gave a strong recommendation that this work should be approached with not just Microsoft, but the most recent Microsoft.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
