Author: dabinsi

If you want to use Nativescript CLI locally instead of globally you can.

To do that go to the root folder of your project and run

npm i --save-dev nativescript

And then to use it locally

npx tns --help

Setup

I found this error while I was following the process to change the edition of a database server from Enterprise to Developer Edition.

The process I was following is described in SQL SERVER – How to Downgrade SQL Server Edition?

Although it is not the exact situation as described there but it was really helpful.

So summarizing and for your convenience here you have the steps I followed:

• Make sure you are not using any feature which is not there in destination edition. This can be done by using catalog view dm_db_persisted_sku_fearures. This should be run on each database to find features.
• Backup ALL the databases before uninstall.
• Make a note of select @@version, sp_configure
• Uninstall the SQL server enterprise edition and install the developer edition. While installing the new edition I changed the instance name.
• Ran select @@version, sp_configure and got a small difference. CLR was not enabled so I ran the next script to enable it.

sp_configure 'show advanced options',1
GO
RECONFIGURE
GO
sp_configure 'clr enabled',1
GO
RECONFIGURE
GO

• The next step is to attach the already existing databases and here is where the problems come:

Confrontation

I was suspecting that the previous SQL Server installation was owning these files so next logical step is to take ownership of those files and have full access to them.

To make this task easier I used the command line as administrator.

To take ownership

takeown /F *.*

And to give me full access to those files

icacls * /grant:r DOMAIN\myuser:F

Conclusion

After run the above commands I went to SQL Server Management Studio and using the menu I could attach all the databases successfully.

To do that let’s use the token “.foreach” in windbg:

@@.foreach (token {!dumpheap -mt 0f43ad08 -short} ) {!do “token”;!objsize “token”;!gcgen “token”}@@

other possible form of this command although I wouldn’t use it for this case. I write it here as an illustration

@@.foreach /pS 4 /ps 3 (token {!dumpheap -mt 07ab0584} ) {!objsize “token”;!gcgen “token”}@@

Happy debugging!!

Using your favorite tool editor, in my case vim, create two files with the next content:

teststaticlib.cpp
///
extern “C” int Test
{
return 123;
}

///

teststaticapp.cpp

///

#include <iostream>

extern “C” int Test();

int main()
{
std::cout << Test() << std::endl;
}

///

To build follow the next steps:

///
1) cl -c teststaticlib.cpp
///
( -c stands for “compiles without linking”)
///
2) lib teststaticlib.obj
///

And the final step is
///
3) cl teststaticapp.cpp teststaticlib.lib
///

Now you can try the exe file just generated.

Enjoy!

NOTE: To check an example using Visual Studio 2012 you may follow this link:
Static linking with Visual Studio

That’s easy :)..

Open Windows Registry and go to the next key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system

There edit the value “EnableLUA” and set it to 0.

Then you have to reboot your windows to make it works.

Enjoy!

Due to the nature of these issues and the fact that the user wasn’t giving too much information about the circumstances surrounding the cases we didn’t have a clue about their origin, and of course we also were not able to apply our developer tools to investigate. The customized application log was not giving useful information either.
The only information we were getting is “…the application freezes and then we have to go to Task Manager and kill the application and start over…”

So, let’s start with getting better information. I prepared a small batch script to install and setup a noninvasive tool and to create a shortcut in their desktop and/or toolbar.
From now on, every time the user was detecting a freeze we asked them to click on the button we had installed to collect better information. In that way the tool created a screenshot, created a memory dump, and finally it killed the application.
The first time we saw the screenshot and confirmed with the memory dump we learned that there was a crash in the application not a hang.

Now with this information and using a “.reg” file to create specifics windows registry key and values, [WER settings|https://msdn.microsoft.com/en-us/library/windows/desktop/bb513638%28v=vs.85%29.aspx||WER Settings] , we configured the workstation to create memory dumps every time the application crashes.
Ok, now we have a couple of memory dump files and learned from them that we’re having the feared heap corruptions. Sometimes when the application was closing or other times when the garbage collector was trying to release some memory we noted the heap corruptions were occurring.
Using “gflags” first and later “application verifier” from Microsoft we tried to reproduce in house and could detect where the heap corruption was happening.

Fine, we have now pinpointed the source code involved in this heap corruption so let’s start in on how to fix it.
Well, this part was not easy either. It was happening in a transition between C++ native and C++ managed code (C++/CLI).
It was happening in a shared class between these two worlds. The transition between these two worlds were not considering the byte alignment of the different primitive types specifically in this case the “bool” type.

Although there are several ways to solve this situation I chose the easiest way, replacing the “bool” type with a “int” type in the class declaration.
Rebuilt the module and Voila! The client has not had any more random freezes/crashes since then.

Happy debugging!