|
fat_boy wrote: Oneys samples are in C
Wrong, they are actually in C++. I didn't know you could write drivers in C++, although people say the best language to write a driver in, is the programming language C, because the kernel of most computers are supported by the C programming language. 
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
TARGETNAME=tampro[c__rdv.exe] could well be the problem. This is the name of the sysfile thats going to be created, so it should be normally just 'tampro'.
|
|
|
|
|
 
Here's the new (error) output:
C:\WINDDK\3790~1.183>cd C:\WINDDK\3790.1830\src\myDrv\Tamper protection
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>build
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objchk_w2K_x86
BUILD: Compile and Link for i386
BUILD: Loading C:\WINDDK\3790~1.183\build.dat...
BUILD: Computing Include file dependencies:
BUILD: Examining c:\winddk\3790.1830\src\mydrv\tamper protection directory for f
iles to compile.
c:\winddk\3790.1830\src\mydrv\tamper protection - 1 source files (7 lines)
BUILD: Saving C:\WINDDK\3790~1.183\build.dat...
BUILD: Compiling (NoSync) c:\winddk\3790.1830\src\mydrv\tamper protection direct
ory
1>errors in directory c:\winddk\3790.1830\src\mydrv\tamper protection
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_w2k_x86\i386 for all platforms
1>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_w2k_x86\i386 for all platforms
1>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
BUILD: Compiling c:\winddk\3790.1830\src\mydrv\tamper protection directory
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_w2k_x86\i386 for all platforms
100>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_w2k_x86\i386 for all platforms
100>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
BUILD: Compile errors: not linking c:\winddk\3790.1830\src\mydrv\tamper protecti
on directory
BUILD: Done
4 files compiled - 8 Errors
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Hmm, thats weird.
Can you build the sample code that comes with the DDK (also in the sources dir).
|
|
|
|
|
I could, but there are so many:
- general
- ime
- input
- kernel
- mmedia
- network
- print
- setup
- smartcrd
- storage
- vdd
- video
- wdm
(including the directory which I'm testing the tamper protection, which is "myDrv")
Which one do you want me to test? 
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Brandon T. H. wrote:
Which one do you want me to test?
Try to find one that has the same include files as yours and see if it builds. If it does then compare its files to yours to try to spot the problem.
|
|
|
|
|
ok
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Richard already spotted it, you are including windows.h. Dont.
|
|
|
|
|
I was having a problem with my laptop always racing, with the temperature super hot - often times just shutting off. I read somewhere that it could be due to dust buildup on the CPU unit. So while it was running, I just puckered up my lips to the louver and blew through, with dust flying up through the keyboard! After a few blows, the laptop is running fine, with the average temperature going down from 80C to 62C!
|
|
|
|
|
The problem with that dust is that it tends to stuff up the ribs of the heat sink like the cork in a bottle. Blowing may remove some of it, but there will always be a lot of dust left. You must pull it out, not push it through. Try inhaling deeply next time.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Seriosly, you just blew big gobs of dust INTO your machine. The dust you saw come out the keyboard was only a fraction of what was lodged in the heatsink. Suck it out with a vacum next time.
|
|
|
|
|
I have been measuring the performance of a multithreaded application and, among other things, have made profiles of memory usage or thread synchronization. I also monitired the load on the CPU cores to get an impression of how well the threads are balanced.
My CPU is an I7 2600k and in the beginning everything looks really nice: The even cores show a load of 5 - 10%, with an occasional spike no larger than 30% when some event is being processed (= I clicked something). The odd numbered cores remain at 0%, so hyperthreading is not used. Then, without any obvious cause, core 0 (where obviously the more damanding threads are running) jumps to 100% and stays there. Looking at the profiles, the behavior of the main thread has changed. It now does not sleep to synchronize with the GPU anymore. It obviously now gets its job done just in time.
First I thought that the program may go crazy at times, but the profiles revealed no such thing. Testing on other machines that this does not happen on a notebook with an i5 processor, but reappears when tested on another i7 machine.
I have noticed a correlation with the CPU core's temperature and suspect that I am seeing some CPU temperature management in action. If the program does not create any unusual CPU load, then CPU 0 must have been clocked down. That would make sense to keep the core's temperature from rising and to draw less power. Something like the reverse of the famous i7 turbo boost. I could live with that if the performance of the application would not suffer from this feature. It appears as if that thing (if it exists) is a bit too eager to save power and starves the application's major threads.
Now, am I looking in the right direction? And what can be done to get a more favorable performance?
At least artificial intelligence already is superior to natural stupidity
modified 29-May-12 8:07am.
|
|
|
|
|
Does the multiplier actually change or is it just a guess?
|
|
|
|
|
I don't get to see any values for the multiplier, but it definitely lowers the clock. I assume that it is this[^] that's behind what I am seeing, but it appears to work the opposite way as described. Sometimes the CPU cooled down and went back to the 'full speed' mode when the temperature of core 0 had dropped.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Maybe.. but just to be sure, get to see the (live) multiplier. Core Temp can do that, or CPU-Z, and there are many other utilities for that.
It seems like far too big a difference for Turbo Boost.
|
|
|
|
|
Here you have a screenshot[^].
I have pasted together two different readings. The one on the left is the 'no sweat mode'. At 1024 x 768 both the CPU and GPU are almost bored. Not bad, considering that the computer is running the database, the webservice and a client with a 3D engine and a UI at the same time. And the CubeMap for the background has 'only' 25 MB, which would have knocked older GPUs out of the socket.
The one to the right was taken when the temperature of core 0 went up. It really looks like it had been throttled down to deliver just the needed performance, as if this Turbo Boost had a brother to do the opposite: Save power and let the CPU cool down.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
There is a mechanism that throttles a CPU down when it gets hot, but 47C isn't even warm. The maximum advised temp for an i7 is 80C, you're not there yet by a long shot. And at 80C it doesn't even begin throttling yet, that's (reportedly) somewhere in the low 90's.
Of course the Turbo will come off at high temperatures (also not at 47C), but that just means it's going back to the normal multiplier down from the increased one. That's not that big a jump - not even 50%, certainly not 93% (corresponds roughly to the 16x difference in utilization).
TL;DR - this makes no sense.
|
|
|
|
|
It must make some sense since another machine (also with an i7) showed exactly the same behavior while a notebook with a slower i5 and some onboard graphics did not. The i5 just kept going in a fairly constant manner.
The other thing that seems interesting is that it appears as if something is trying to let the CPU run exactly at the required level, no more or less. It also seems to adapt very quickly when there is a sudden demand for more. The UI thread gets more active as soon as I start clicking buttons. The webservice is called for data, views are opened, controls are initialized and styles are loaded. A lot of more activity on the CPU, yet there is no noticable delay or additional roughness in the animations.
The profiles also show this. The rendering thread pushes its data to the GPU and then sleeps until the next frame when the CPU runs normally. As soon as it goes into this 100% mode, the synchronization is almost too short to be seen. As if something had estimated exactly how fast the CPU had to be to make a spot landing. The framerate drops a little, but I think that once in a while the CPU simply does not make it in time and misses a frame. Still, this does not change when the CPU gets more to do.
This would probably be ok, but why does the scheduler let most threads run on CPU 0? And how can I persuade it to make more use of the other cores?
Edit: Aha! This[^] already sheds some light on the whole thing! Indeed the Turbo Boost or the thermal shutdown appear to be only part of the functionality. It is a power saving and heat reducing mechanism, just as I suspected. It makes sense, but is also a little in the way when measuring performance.
At least artificial intelligence already is superior to natural stupidity
modified 29-May-12 15:30pm.
|
|
|
|
|
Right there's also SpeedStep and its descendants, but it doesn't change the performance by 16 times either so that still doesn't explain how 6% goes to 100%, does it?
|
|
|
|
|
Just looking into it, but there is lots of talk from people who have failed or succeeded at overclocking the CPU and only little details. You are right, it does not appear as if it could keep the CPU so constantly at 100%. Still, it's the best candidate so far. With the CPU used so little it could indeed decide to go to its lowest setting.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
So, just in case this isn't caused my hardware but by software, why don't you go check how the multiplier changes when it goes into "100% mode"?
|
|
|
|
|
I will, but it must wait until tomorrow. Disabling Speedstep in the BIOS changed nothing. It still switches when core 0 reaches 46 degrees and switches back when the temperature falls back below that mark. Very interesting. And thanks for your replies.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Could you accidentally have set your OS's cooling policy to passive? It would do something like that.
edit: now that I think about it, a performance difference of 16x still seems rather extreme.
|
|
|
|
|
I will take a look. Thanks!
Edit: Nope, it's set to active. I don't think I ever changed it.
At least artificial intelligence already is superior to natural stupidity
modified 29-May-12 17:31pm.
|
|
|
|
|
I am currently developing an application on Windows XPe that requires the XPe host to run a RAS server that uses a serial modem.
When XPe starts the RAS server fails to start correctly up to 50% of the time.
The log file "ModemLog_Communications cable between two computers" reads the following when the RAS server fails to come up:
05-24-2012 15:58:53.421 - File: C:\WINDOWS\system32\tapisrv.dll, Version 5.1.2600
05-24-2012 15:58:53.421 - File: C:\WINDOWS\system32\unimdm.tsp, Version 5.1.2600
05-24-2012 15:58:53.421 - File: C:\WINDOWS\system32\unimdmat.dll, Version 5.1.2600
05-24-2012 15:58:53.421 - File: C:\WINDOWS\system32\uniplat.dll, Version 5.1.2600
05-24-2012 15:58:53.437 - File: C:\WINDOWS\system32\drivers\modem.sys, Version 5.1.2600
05-24-2012 15:58:53.437 - File: C:\WINDOWS\system32\modemui.dll, Version 5.1.2600
05-24-2012 15:58:53.437 - File: C:\WINDOWS\system32\mdminst.dll, Version 5.1.2600
05-24-2012 15:58:53.437 - Modem type: Communications cable between two computers
05-24-2012 15:58:53.437 - Modem inf path: mdmhayes.inf
05-24-2012 15:58:53.437 - Modem inf section: M2700
05-24-2012 15:58:53.437 - Matching hardware ID: pnpc031
05-24-2012 15:58:53.437 - Opening the modem device failed with error 00000005
And the following when successful.
05-24-2012 16:51:00.531 - File: C:\WINDOWS\system32\tapisrv.dll, Version 5.1.2600
05-24-2012 16:51:00.531 - File: C:\WINDOWS\system32\unimdm.tsp, Version 5.1.2600
05-24-2012 16:51:00.531 - File: C:\WINDOWS\system32\unimdmat.dll, Version 5.1.2600
05-24-2012 16:51:00.531 - File: C:\WINDOWS\system32\uniplat.dll, Version 5.1.2600
05-24-2012 16:51:00.546 - File: C:\WINDOWS\system32\drivers\modem.sys, Version 5.1.2600
05-24-2012 16:51:00.546 - File: C:\WINDOWS\system32\modemui.dll, Version 5.1.2600
05-24-2012 16:51:00.546 - File: C:\WINDOWS\system32\mdminst.dll, Version 5.1.2600
05-24-2012 16:51:00.546 - Modem type: Communications cable between two computers
05-24-2012 16:51:00.546 - Modem inf path: mdmhayes.inf
05-24-2012 16:51:00.546 - Modem inf section: M2700
05-24-2012 16:51:00.546 - Matching hardware ID: pnpc031
05-24-2012 16:51:00.593 - 115200,8,N,1, ctsfl=0, rtsctl=1
05-24-2012 16:51:00.593 - Initializing modem.
05-24-2012 16:51:00.593 - Waiting for a call.
How can I debug this and figure out why Windows fails to set up the modem correctly all the time?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
