Pretty old topic but still no really good solution or workaround exists there on how to make DST working properly with the EWF enabled.
There has a bunch of suggestion been on how to make those two live together posted in the newsgroup: from using undocumented system's RealTimeIsUniversal flag to making your own time monitoring application that will switch or correct the system time if a DST time switch happens.
Perhaps, the only workaround that would work correctly is to disable the DST. Well, I can barely call this a workaround but at least with the DST off you won't have issues with the time changing unpredictably.
How to disable DST? Easy, just set this registry flag at run time:
[HKLM\System\CurrentControlSet\Control\TimeZoneInformation], "DisableAutoDaylightTimeSet"=dword:1
On related note, you can mess around time zone settings offline in TD if you explorer the following key:
[HKLM\System\CurrentControlSet\Control\TimeZoneInformation].
More info about this can be found on this XPe tip here.
Sunday, April 8, 2007
Friday, April 6, 2007
XPe tip #16: Can be Eval SLX re-used?
Recently I answered the following question in the newsgroup: is it possible to re-use SLX project created with eval version of the Toolkit with purchased copy of the tools?
We all know that there is no (easy) way to re-use database of eval installation with the full version of the toolkit. If you use it, you are going to end up with eval runtimes.
However, using the SLX (original project) create with eval version with either eval or non-eval versions of the toolkit is perfectly fine as long as you follow the following rules:
- You install the full (non-eval) version of the toolkit properly. You will have to completely uninstall eval version first including database.
- You re-import all the custom SLDs you've created to support that SLX project in to the non-eval database.
- You type in the right PID number in the RunTime field on Configuration Settings page of the loaded SLX in non-eval TD.
We all know that there is no (easy) way to re-use database of eval installation with the full version of the toolkit. If you use it, you are going to end up with eval runtimes.
However, using the SLX (original project) create with eval version with either eval or non-eval versions of the toolkit is perfectly fine as long as you follow the following rules:
- You install the full (non-eval) version of the toolkit properly. You will have to completely uninstall eval version first including database.
- You re-import all the custom SLDs you've created to support that SLX project in to the non-eval database.
- You type in the right PID number in the RunTime field on Configuration Settings page of the loaded SLX in non-eval TD.
Wednesday, April 4, 2007
XPe tip #15: More useful tools..
Continue finding good stuff on the NirSoft site.
Not sure how many times I had to use "at" command on embedded. Especially when I had to launch a command line within LocalSystem context (/interactive switch). Although always had to calculate timing and do a few additional commands in order to schedule and then delete the properly configured "at" command. Now I won't have all this problems with another NirSoft's utility - AtNow
Some good stuff for doing Window sniffing - from class names to style/ex-styles and etc. Two really nice utilities - WinListener and WinExplorer. The second is really good as it allows you to modify all the windows parameters via GUI instead of messing with the code and SetWindowsPos API calls.
Tools like ExeInfo and DLL Export Viewer are also nice. But there are lots of similar tools on the Web. Also, I am a fan of FAR Commander and a few plug-ins there do similar PE analisys and produces even better, more detail and visual results.
In driver and service area - ServiWin. Not as good as devcon but nice GUI makes it easier to see and filter out specific driver services. Also, it shows dependencies which is realy helpful on XP Embedded.
The CurrProcess tool is an extremely simplified clone of ProcessExplorer from sysinternals. Advantages - small and requires less dependencies in the image.
ActiveXHelper could be considered as an embedded [read: simplified] version of Microsoft OLEView tool.
DumpEDID and MonitorInfoView -interesting tools. Don't yet know how I am going to use them but I will.
USBDeview - useful, no doubt. Especially the stop/disconnect function. Although if I needed more info on a particular USB device or even a deep look into the interfaces and protocols exposed by the device, I would use an USB Analyzer.
ShellExView - could be useful when dealing with Shell extensions and namespaces issues.
OpenedFilesView - I am probably going to switch to this from similar sysinternals tools.
Many, many more tools there. Explore the utils part of the website by yourself!
Not sure how many times I had to use "at" command on embedded. Especially when I had to launch a command line within LocalSystem context (/interactive switch). Although always had to calculate timing and do a few additional commands in order to schedule and then delete the properly configured "at" command. Now I won't have all this problems with another NirSoft's utility - AtNow
Some good stuff for doing Window sniffing - from class names to style/ex-styles and etc. Two really nice utilities - WinListener and WinExplorer. The second is really good as it allows you to modify all the windows parameters via GUI instead of messing with the code and SetWindowsPos API calls.
Tools like ExeInfo and DLL Export Viewer are also nice. But there are lots of similar tools on the Web. Also, I am a fan of FAR Commander and a few plug-ins there do similar PE analisys and produces even better, more detail and visual results.
In driver and service area - ServiWin. Not as good as devcon but nice GUI makes it easier to see and filter out specific driver services. Also, it shows dependencies which is realy helpful on XP Embedded.
The CurrProcess tool is an extremely simplified clone of ProcessExplorer from sysinternals. Advantages - small and requires less dependencies in the image.
ActiveXHelper could be considered as an embedded [read: simplified] version of Microsoft OLEView tool.
DumpEDID and MonitorInfoView -interesting tools. Don't yet know how I am going to use them but I will.
USBDeview - useful, no doubt. Especially the stop/disconnect function. Although if I needed more info on a particular USB device or even a deep look into the interfaces and protocols exposed by the device, I would use an USB Analyzer.
ShellExView - could be useful when dealing with Shell extensions and namespaces issues.
OpenedFilesView - I am probably going to switch to this from similar sysinternals tools.
Many, many more tools there. Explore the utils part of the website by yourself!
XPe tip #14: The best command line ever
While googling for some API call info I recently hit one website - NirSoft - that had a lot of nice tools and source code very useful for hacking and etc. We all know that we often have to do reverse engineering on embedded in order to understand, use or fix some system components functionality.
I am not going to talk about all the tools on that website but just one that made my day - NirCmd. Note: it is freeware! So much functionality in just one relatively small utility.
I have written myself tons of tools and utilities for embedded, even merged some of them. But never had so many functions implemented in one command line application.
The function I personally loved is - changing display settings on the fly. You just pass in the resolution and bit rate and you are done. Best of all, in some intermittent version they added refresh rate parameter.
Comment: the tool works great on Vista as well. This makes my life on Vista MCE much easier. Basically I can play with any TV (SD, HD, etc.) and have no wear the resolution rate is not supported or, on embedded, having no way to fix resolution problems without Display Control Panel applet included in the image.
Another tools that may be useful in changing screen resolutions and, more important, screen refresh rate is ChRes.exe. This utility is much simpler and all it does is calling to ChangeDisplaySettingsEx API. More about this tool you can find here.
I am not going to talk about all the tools on that website but just one that made my day - NirCmd. Note: it is freeware! So much functionality in just one relatively small utility.
I have written myself tons of tools and utilities for embedded, even merged some of them. But never had so many functions implemented in one command line application.
The function I personally loved is - changing display settings on the fly. You just pass in the resolution and bit rate and you are done. Best of all, in some intermittent version they added refresh rate parameter.
Comment: the tool works great on Vista as well. This makes my life on Vista MCE much easier. Basically I can play with any TV (SD, HD, etc.) and have no wear the resolution rate is not supported or, on embedded, having no way to fix resolution problems without Display Control Panel applet included in the image.
Another tools that may be useful in changing screen resolutions and, more important, screen refresh rate is ChRes.exe. This utility is much simpler and all it does is calling to ChangeDisplaySettingsEx API. More about this tool you can find here.
Tuesday, April 3, 2007
XPe tip #13: SID issues
We all know about possible issues that duplicated SIDs can create in your system setup and open a security hole on the network [ok, if you don't, read this]. Probably the best explanation to these issues were given by Mark Russinovich and Bryce Cogswell on the documentation page for NewSID tool.
Anyway, I am not writing this to start another thread on the SID duplication problem (if you Google for it, there are tons of similar discussion on the subject). I have recently answered a question in the newsgroup where the poster was surprised by not seeing the SIDs under HKEY_USERS key. It appeared that he was looking for long GUID-like subkeys but was playing with Minlogon based image. Here is the thread. As you may read, the poster was looking for actually Admin or User account SID which is not supported by Minlogon.
User SID duplication is not much an issue in Minlogon environment. However, there is still computer SID. You can find that SID somewhere in SAM hive (HKLM\SECURITY\SAM), typically listed in the list of Members keys. Much easier way to find out that SID though is to run PsGetSid utility from sysinternals.com. Here is where you can download it as a part of PsTools package.
Here is a list of well-known SIDs defined by Microsoft.
The one you're definitely going to catch with Minlogon image is S-1-5-18, a special account used by the operating system (aka LocalSystem account).
For Administrator account you would be looking for something like S-1-5-21-191058668-193157475-1542849698-500 on Winlogon images only. The only bolded part is machine dependent and generated randomly. All user accounts on the same system are going to have incrementally increased four last digits of the SID shown above. (1000, 1001, etc. instead of 500).
You can see the list of SIDs assigned to the user accounts on your system by exploring subkeys under [HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList] key.
And last, the good intro into what SID is on MSDN.
Anyway, I am not writing this to start another thread on the SID duplication problem (if you Google for it, there are tons of similar discussion on the subject). I have recently answered a question in the newsgroup where the poster was surprised by not seeing the SIDs under HKEY_USERS key. It appeared that he was looking for long GUID-like subkeys but was playing with Minlogon based image. Here is the thread. As you may read, the poster was looking for actually Admin or User account SID which is not supported by Minlogon.
User SID duplication is not much an issue in Minlogon environment. However, there is still computer SID. You can find that SID somewhere in SAM hive (HKLM\SECURITY\SAM), typically listed in the list of Members keys. Much easier way to find out that SID though is to run PsGetSid utility from sysinternals.com. Here is where you can download it as a part of PsTools package.
Here is a list of well-known SIDs defined by Microsoft.
The one you're definitely going to catch with Minlogon image is S-1-5-18, a special account used by the operating system (aka LocalSystem account).
For Administrator account you would be looking for something like S-1-5-21-191058668-193157475-1542849698-500 on Winlogon images only. The only bolded part is machine dependent and generated randomly. All user accounts on the same system are going to have incrementally increased four last digits of the SID shown above. (1000, 1001, etc. instead of 500).
You can see the list of SIDs assigned to the user accounts on your system by exploring subkeys under [HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList] key.
And last, the good intro into what SID is on MSDN.
Monday, April 2, 2007
XPe tip #12: SetupAPI - nothing is more helpful than logging!
To continue my previous post to this blog I want to mention another great tool that is always available to us, XPe developers, on target systems. When I say always I assume the right components are included - kernel and "Primitive: Setupapi". But you can barely find an XPe image that doesn't have the last component added.
Anyway, what is the SetupAPI log? It is a set of API functions that a setup application calls to perform application installation operations. The functions are available to develop a setup application that can install any type of application, from driver to user mode app. MSDN has a big and nice section dedicated to Setup API.
Since most of the issues we are fighting with on XPe are often related to components we ain't provided with source code for, especially third party drivers, having at least a way to analyze failures of those components with the logging tool is a great thing.
Anyway, some quick details for those who never dealt with Setu API logs. By Default the log is centrally located under %windir% folder and called setupapi.log. There are some registry entries to set up and configure how you want the logging to be performed. E.g., the most important value for us is logging level. Often the default log level is not enough to find out what's missing or went wrong with the image. So, increasing the level may help to get more information about the failures and possible get on the right track fixing them.
Here is the instructions on how you increase the log level. SourceQuest also has a freeware GUI utility that allows you to modify SetupAPI configuration parameters without remembering all the configuration registry paths. That utility - suplog.exe, which is already there and available for download, aims to simplify the capture and display of SetupAPI logs. BTW, changing most of the settings is dynamic and will be picked up by the new loaded instance of the app being installed and analyzed.
Quick note here. There is a very useful option for SetupAPI available that allows you to direct the logging to debugger output that you can easy capture with DebugView tool from sysinternals.com. It gives you a nice control over the log for your only component that you are trying to install at run time.
Anyway, what is the SetupAPI log? It is a set of API functions that a setup application calls to perform application installation operations. The functions are available to develop a setup application that can install any type of application, from driver to user mode app. MSDN has a big and nice section dedicated to Setup API.
Since most of the issues we are fighting with on XPe are often related to components we ain't provided with source code for, especially third party drivers, having at least a way to analyze failures of those components with the logging tool is a great thing.
Anyway, some quick details for those who never dealt with Setu API logs. By Default the log is centrally located under %windir% folder and called setupapi.log. There are some registry entries to set up and configure how you want the logging to be performed. E.g., the most important value for us is logging level. Often the default log level is not enough to find out what's missing or went wrong with the image. So, increasing the level may help to get more information about the failures and possible get on the right track fixing them.
Here is the instructions on how you increase the log level. SourceQuest also has a freeware GUI utility that allows you to modify SetupAPI configuration parameters without remembering all the configuration registry paths. That utility - suplog.exe, which is already there and available for download, aims to simplify the capture and display of SetupAPI logs. BTW, changing most of the settings is dynamic and will be picked up by the new loaded instance of the app being installed and analyzed.
Quick note here. There is a very useful option for SetupAPI available that allows you to direct the logging to debugger output that you can easy capture with DebugView tool from sysinternals.com. It gives you a nice control over the log for your only component that you are trying to install at run time.
XPe tip #11: Debugging - VS2005 and WinDbg
On Embedded devices we are often required to do some debugging various issues from driver install to application flow. With regards to applications and anything running in user mode everything is simple and straightforward - just stick to Microsoft Visual Studio (better the latest and greatest - VS2005 or coming Orcas) with Remote Debugging feature (firewall caveat on SP2). But how to handle driver debugging?
No easy answer there. The only option is probably KD (Kernel Debugger). There are a few debugger on the market (WinDbg, SoftIce, etc.) but I tend to think for XP and later only WinDbg has the real power to keep up with Microsoft changing environment. The latest version (6.6.7.5 to the moment) has lots of nice new features, although for XPe development we probably only need the basics. So, the winner is WinDbg (obviously, only 32-bit version is interesting option for us, XPe developers).
It requires a little bit of effort to setup the debugger to connect remotely your development PC, where you install the WinDbg tools, and target machine. Here is how you can enable remote debugging on SP2 (firewall setup, policies and etc.). And don't forget to setup the symbols.
For XP(e) you'd probably stick to COM or 1394 debugging. For Vista targets I loved the USB 2.0 kernel debugging support feature.
And you can certainly use WinDbg to debug services.
Very nice tutorial and lots of useful info about debugging with WinDbg I happened to fin on my favortie CodeProject.
No easy answer there. The only option is probably KD (Kernel Debugger). There are a few debugger on the market (WinDbg, SoftIce, etc.) but I tend to think for XP and later only WinDbg has the real power to keep up with Microsoft changing environment. The latest version (6.6.7.5 to the moment) has lots of nice new features, although for XPe development we probably only need the basics. So, the winner is WinDbg (obviously, only 32-bit version is interesting option for us, XPe developers).
It requires a little bit of effort to setup the debugger to connect remotely your development PC, where you install the WinDbg tools, and target machine. Here is how you can enable remote debugging on SP2 (firewall setup, policies and etc.). And don't forget to setup the symbols.
For XP(e) you'd probably stick to COM or 1394 debugging. For Vista targets I loved the USB 2.0 kernel debugging support feature.
And you can certainly use WinDbg to debug services.
Very nice tutorial and lots of useful info about debugging with WinDbg I happened to fin on my favortie CodeProject.
Subscribe to:
Posts (Atom)
.gif){kind=small}