This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Publisher
- :
- FlexNet Publisher Forum
- :
- Re: Microsoft C++ exception: FNPNS::TSM::CDoesNotExistException at memory location ...
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 13, 2009
08:26 AM
Microsoft C++ exception: FNPNS::TSM::CDoesNotExistException at memory location ...
Microsoft C++ exception: FNPNS::TSM::CDoesNotExistException at memory location...
What's the cause for this exception? We have this in our native C++ projects using the FNP 11.6 API and Visual Studio 2005 (not causing any crashes). It seems to occur at every API function call.
Edit:
The exception comes from FLEXnet Publisher at every API call and seems to be handled internally by FNP.
What's the cause for this exception? We have this in our native C++ projects using the FNP 11.6 API and Visual Studio 2005 (not causing any crashes). It seems to occur at every API function call.
Edit:
The exception comes from FLEXnet Publisher at every API call and seems to be handled internally by FNP.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 02, 2009
06:11 AM
Ok, since nobody seems to know anything about this I'll post the answer I got from the support:
These exceptions are thrown by design to communicate that an object or section, for example, does not exist in trusted storage. It is often completely valid for such an item not to exist in Trusted Storage.
The ATL exception similarly is thrown by Microsoft design, from memory it is related to our setting ATL security code.
Whilst a concern for the performance impact of exception throwing has historically been an issue, this is regarded as less so nowadays. The time for exception throwing/catching a standard exception is in the region of a 1000th of a millisecond – at least on Windows.
These exceptions are thrown by design to communicate that an object or section, for example, does not exist in trusted storage. It is often completely valid for such an item not to exist in Trusted Storage.
The ATL exception similarly is thrown by Microsoft design, from memory it is related to our setting ATL security code.
Whilst a concern for the performance impact of exception throwing has historically been an issue, this is regarded as less so nowadays. The time for exception throwing/catching a standard exception is in the region of a 1000th of a millisecond – at least on Windows.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 29, 2020
02:32 PM
Is this explanation of exceptions correct now in 2020? Version of FNP is 11.16.